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ABSTRACT 


There are two main purposes to this thesis study. First, we will deploy the 
principles of software development that we have learned at NPS and test its validity 
through the development of a real world system. This system will be a completely self 
sustaining prototype of a web-based interactive military uniform regulation manual. 
Second, we will conduct a study of Human Computer Interaction (HCI) through the 
design and usability testing of the new interactive uniform regulations manual. All 
military services currently possess their own individual uniform regulations specific to 
each service. This system, although specifically designed for the United States Marine 
Corps, can be used as a model for any other service as well as any international military 
desiring a similar solution to the inherent problems associated with current manuals. The 
new system will address all aspects currently outlined in the regulations. This regulation 
will be used by all US civilians and military service members to whom the current 
manual is now relevant. Although we fully intend to deliver a finished product to the 
Marine Corps for their official use, the true value to us as students is in the process of 
developing and testing this new system. The knowledge learned here will benefit us in 
any future system design or development projects. 
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I. 


INTRODUCTION 


The two main purposes of this thesis study are to deploy the principles of software 
development that we have learned at NPS and test their validity through the development 
of a real world system. This system we developed is a completely self sustaining 
prototype of a web-based interactive military uniform regulation manual. Second, we 
conducted a study of Human Computer Interaction (HCI) through the design and 
usability testing of the new interactive uniform regulations manual. All military services 
currently possess their own individual uniform regulations specific to each service. This 
system, although specifically developed for the United States Marine Corps, can be used 
as a model for any other service as well as any international military desiring a similar 
solution to the inherent problems associated with current manuals. The new system 
addresses all aspects currently outlined in the regulations. This regulation can be used by 
all US civilians and military service members to whom the current manual is now 
relevant. Although the finished product is ready for official use by the Marine Corps, the 
true value to us as students was in the process of developing and testing this new system. 
The knowledge learned here will benefit us in any future system design or development 
projects. 

The benefits of studying the iterative process of software development are 
invaluable to any Computer Scientist. In our capacity as military officers, whether in the 
US Military or the German Armed Forces, we will be involved in the development of 
new military software systems. Whether it is as procurement officers, advisors, or full 
project managers, we will need to possess the skills inherent to software development. 
Regardless of the role, the experience necessary to handle the intricacies required in 
software development is difficult to acquire. We will be confronted with situations that 
require close interaction with civilian contractors who already have years of experience in 
this field. We will need to have a skill set to assess the functionality of proposed systems 
and intelligently challenge the contractors. This thesis will allow us the best opportunity 
to develop these skills in the most expeditious manner. 
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The scope of this thesis was to create an easy to use web-based graphical user 
interface (GUI) based uniform regulation guide along with the design and creation of a 
server required to house such a web site. The guide was implemented using primarily 
visual aides and follows the practices of good Macro/Micro Human Computer Interaction 
(HCI) Design. The aim was to provide the needed information to the user in an intuitive 
GUI interface that requires minimal “mouse clicks” to retrieve the desired information 
and we feel that we have satisfied that requirement. The guide also provides the user 
with alternative text from the current regulations manual dealing with the specific 
uniform in question. The end result is an easy to use research tool that may be utilized by 
any Marine to ensure that their uniform is within regulations. Our anticipated server 
requirements were to develop a system that was self contained and independent of 
existing hardware/software requirements of the proposed client group. For that purpose, 
we specifically used the open source software Apache HTTP Web servers, PHP (> 
version 4), and MySQL. Our design allows the client side to use any available web 
browser. 

The documentation provided here details our research and progress for this 
project. In Chapter II we provide background information of the current problems with 
the existing Marine Corps uniform regulations manual. We detail how we intend to meet 
the needs of the intended users of this new system. We also provide some general 
background information regarding the Unified Process for software development that we 
followed throughout development of this application. We chose to follow the Unified 
Process mainly because it is the state-of-practice in today’s software industry, which was 
taught to us here at NPS, and it is the process that we felt most comfortable with. In this 
chapter, we outline the Unified Process with particular emphasis on the importance of use 
cases. We end the chapter with a close look at HCI and the concerns associated with 
good web design from an aesthetic point of view. 

Chapter III is where we provide a detailed account of our journey through this 

entire process. We breakdown the Inception Phase, the Elaboration Phase, the 

Construction Phase, and the Transition Phase and discuss how we approached each phase 

within the framework of the Unified Process. Here you will find how we created our use 

cases and how we fully developed our requirements for this site. Our complete 
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Requirements Document can be found in Appendix I but we summarize it in Chapter III. 
We also outline our design strategy which puts us into the Elaboration Phase. During this 
phase we mapped out our ideas for a design that will meet the specific requirements of 
the Inception Phase. We again summarize our System Design Specification which can be 
found in Appendix II. In Chapter III we also discuss our security measures, evolution, 
risk analysis, and our approach to the HCI issues outlined in Chapter II. 

In Chapter IV we detail the testing phases of the prototype. We conducted three 
formal rounds of testing with three different populations. Our testing audience grew with 
each round as well as the functionality of the application during the tests. Chapter V 
concludes our work with a look at future work still left to be done in this area. 

It is important to keep in mind that although we were able to create a valuable 
product that serves a needed purpose for the Marine Corps, it is the process and not the 
product that is the focus of this thesis. There are countless books and web sites available 
to offer guidance on practices for good web site development. In our research, we 
discovered that the majority of these references only cover the aesthetics of web design 
and deal primarily with efficient layouts of web pages. The focus is on the product and 
neglects to give solid details of the process required for effective web design. In today’s 
enormous e-commerce market, web sites that are being built are extremely complicated 
and intricate and rival the complexities of a large software development project. We can 
find several types of software development processes, one of which is the Unified 
Process followed here, that are currently being used to help software developers navigate 
through developing software systems. The software engineering discipline is focused on 
improving the software development process to allow for on-time and on-budget software 
but there lacks the same guidance for the web site development process. This lack of 
regulation is puzzling since, after all, web sites are software and, with the growing 
functionality found in today’s web sites, suffer the same shortfalls of software such as 
budget and schedule. 

We have attempted to prove our point that since web sites behave exactly like 
software, they should be able to be developed with the same process. We attempted to 
use the well known Unified Process for complex software system development and 
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develop a complex web site with it. Our approach was to follow the Unified Process 
learned here at the Naval Postgraduate School as closely as possible and use it in 
developing a web based uniform regulations manual for the United States Marine Corps. 
We took a rather large liberty in that our team played both the role as developer and 
customer. We did not officially involve the United States Marine Corps in developing 
this site since, again, it was the process that was our main interest. Since one of our 
thesis members is a US Marine, we felt that we could adequately play both roles and still 
accomplish our goal of this thesis. We thoroughly tested the web site on active duty 
Marines, as described in Chapter IV of this document, so we feel confident that we 
accurately represented the intended users of this site. This document states our results. 
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II. BACKGROUND 


A. INTRODUCTION 

The current official Marine Corps Uniform Regulations Manual is available in 
hardcopy or PDF only. There are some web based manuals that can be found on the 
internet but none of them are designated as an “official” source for information by 
Headquarters Marine Corps. There is not a Graphical User Interface system currently in 
existence for this information, and in its current form, the manual is not well written in an 
easy to use manner. 

Major issues/concerns with the existing manual: 

• Different services have different manuals; there is no “single-instance” 
access available covering all services. 

• Manuals may require multiple pages to be repeatedly referenced before 
being fully understood. 

• Verbiage can be distracting and cause regulations to be misunderstood. 

• It does not provide a “quick reference” for user convenience. 

• Changes to regulations require entire manuals to be generated and 
replaced, leading to older versions with outdated materials still in 
circulation. 

• Not written to be “user intuitive”. 

• Even experienced users can have problems quickly accessing the 
information they require. 

• The following is a list of items that must be supported in order for our 
system to properly meet the needs of current users: 

• Reference uniform components and items for the prescribed uniform of 
the day (e.g. what comprises Service Dress Bravo?) 

• Reference allowed locations to wear a particular uniform (e.g. Cammies 
not allowed off base for Marines) 

• Identification of medals and ribbons 

• Reference order of precedence for medals and ribbons 

• Identification of all uniform insignia 

• Identify correct location for all uniform insignia as well as for medals and 
ribbons 
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• Identify correct location for uniform components (e.g. proper wearing of 
cover, proper length of tie or pant leg) 

• Reference any accessories allowed and their proper wear or usage (e.g. 
purse or umbrella) 

• Reference proper grooming standards 

• Miscellaneous uniform issues 

B. UNIFIED PROCESS 

The Unified Process is a popular iterative and incremental software development 
process. It should be viewed more as a framework which can be customized for specific 
software development projects. According to (Brugee and Dutoit, 2003) 

The unified process distinguishes important time ranges called “cycles” in the 
lifetime of a software system. Note that these are different from the cycles in the spiral 
model: they can be thought of as characterizing the stage of maturity of the software 
system during its lifetime...A cycle generally ends with a release of the system as a 
product to the customer. Each cycle can be in one of four states called phases: Inception, 
Elaboration, Construction, and Transition. 

All four phases are divided into a series of time driven iterations that can be 
revisited after the process has started. Each iteration results in an increment, which is a 
release of the system that contains added or improved functionality compared with the 
previous release. Figure 1 shows how the relative emphasis of different disciplines 
changes over the course of a project. Although most iterations will include work in most 
of the process disciplines (e.g. Requirements, Design, Implementation, Testing) the 
relative effort and emphasis will change over the course of the project. 
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Figure 1. Unified Process 

The following is a brief synopsis of each phase based on The Unified Process 
explained by (Scott, 2001): 

Inception Phase: 

Inception is the smallest phase in the project, and ideally it should be quite short. 
If the Inception Phase is long then it is usually an indication of excessive up-front 
specification, which is contrary to the spirit of the Unified Process. 

The following are typical goals for the Inception phase. 

• Establish a justification or business case for the project 

• Establish the project scope and boundary conditions 

• Outline the Use Cases and key requirements that will drive the design 
tradeoffs 

• Outline one or more candidate architectures 

• Identify risks 

• Prepare a preliminary project schedule and cost estimate 

The Lifecycle Objective Milestone marks the end of the Inception phase. 
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Elaboration Phase: 


During the Elaboration phase the project team is expected to capture a healthy 
majority of the system requirements. However, the primary goals of Elaboration are to 
address known risk factors and to establish and validate the system architecture. 

The architecture is validated primarily through the implementation of an 
Executable Architecture Baseline. This is a partial implementation of the system which 
includes the core, most architecturally significant, components. It is built in a series of 
small, timeboxed iterations. By the end of the Elaboration phase the system architecture 
must have stabilized and the executable architecture baseline must demonstrate that the 
architecture will support the key system functionality and exhibit the right behavior in 
terms of performance, scalability and cost. 

The final Elaboration phase deliverable is a plan (including cost and schedule 
estimates) for the Construction phase. At this point the plan should be accurate and 
credible since it should be based on the Elaboration phase experience and since 
significant risk factors should have been addressed during the Elaboration phase. 

The Lifecycle Architecture Milestone marks the end of the Elaboration phase. 

Construction Phase: 

Construction is the largest phase in the project. In this phase the remainder of the 
system is built on the foundation laid in Elaboration. System features are implemented in 
a series of short, timeboxed iterations. Each iteration results in an executable release of 
the software. 

The Initial Operational Capability Milestone marks the end of the Construction 

phase. 

Transition Phase: 

The final project phase is Transition. In this phase the system is deployed to the 
target users. Feedback received from an initial release (or initial releases) may result in 
further refinements to be incorporated over the course of several Transition phase 
iterations. The Transition phase also includes system conversions and user training. 
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The Product Release Milestone marks the end of the Transition phase. 

It is important to remember that the Unified Process described above is designed 
to be tailored to the needs of the project. It is only a framework that provides loose 
guidance for developing a software system but is structured enough to clearly define each 
phase and desired goals of each. 

C. CURRENT PROBLEMS WITH WEB DESIGN 

One of the biggest problems with any software development is clearly stating and 
understanding the user’s needs. There are several factors that lead to problems with 
clearly defining system requirements, which have been the subject of much research, but 
we are going to focus on the disconnect between client and designer in the requirements 
stage. Web design suffers from this problem in that projects are delayed due to a lack of 
understanding during the requirements stage and our research here attempts to explore a 
possible solution. 

Poor understanding of target user needs or a client’s vision, ineffective use of 
limited resources, misguided emphasis on the wrong design priorities, over-emphasis on 
technologies all will contribute to a failed, late, inappropriate or too-expensive website. 
Experience can teach us how to avoid pitfalls, but the greatest lesson can be learned by 
the least experienced: the earlier that purpose and goals are clearly defined and recorded, 
the more easily problems are identified and solved, the easier it is to stay focused, and the 
better the result is for everyone. 

Somewhat surprisingly, web developers seem reluctant to adopt methods and 
approaches from other disciplines that could reduce their problems. Particularly during 
the crucial initial phase of projects, web design can benefit from emulating certain 
software engineering practices, including the Unified Process. (Cockburn, 2001) 

D. INTRODUCING USE CASES 

Use cases provide a simple, fast means to decide and describe the purpose of a 
project. They are successfully employed by many software engineers as a way to capture 
the high-level objectives of an application during the initial phase of development. There 
is no reason that web site developers should not also benefit from a use-case driven 
approach. Even a project that initially seems straightforward can balloon into an 
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unmanageable behemoth if the purpose is not always at the forefront of development. To 
define a project’s use cases, we need to consider two concepts, and how they relate: 

• the actors 

• the goals 

Actors are everyone and everything that will use, or be used, by the system. It 
should be noted here that “system” is being used to describe the generic idea of use cases 
but in the context of our thesis, “system” and “web site” are interchangeable. Goals are 
what one, some, or all of the actors want to achieve. To be complete, every use case must 
describe a specific goal and the actors that will perform tasks to achieve that goal. 
(Larman, 2004) 

The actors are external to our system so we cannot control their behavior or inputs 
but we can make certain assumptions about what is expected from an actor to achieve a 
goal. The most obvious actor in the case of any website is a visitor to the site which in 
our case, our expected users are U. S. Marines. We assume that the actors are visiting 
our site to attain information about some part of their uniform but in general, users visit 
sites for several reasons, depending on the purpose of the web site. Actors are not 
necessarily human, as seen in our Requirements Document found in Appendix I, we have 
included the database as an “actor”. Whatever our vision, use cases will describe the 
goals achieved by actors who perform tasks. 

1. An Example of Use Cases 

A weblog enables its owners to communicate thoughts about a topic and others to 
read them and perhaps respond. The obvious weblog actors are the authors and the 
visitors to the web log. The author plays the role of generating the content and the visitor 
plays the role of reading the content and responding. The goals are to inform and to be 
informed. 

After a little brainstorming, we could decide that some of these actors’ tasks 
should include reading an item, creating, editing, and deleting blog content, commenting, 
syndicating, and some administrative tasks, such as controlling access, permissions, and 
accounts. Some of these tasks are common to all actors and some may be exclusive to a 
single actor. All of them can be encapsulated in a use case that describes our initial idea: 
“Publish Weblog”. 
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This use-case diagram illustrates the relationship between actors and goals: 


^ Publish Weblog ^-- - - 

Visitor Author 


Figure 2. Use case Diagram 

Use-case diagrams make it easier to think about the relationships or dependencies 
between use cases and actors. Perhaps visitors and authors would like to be able to 
search for particular content already published in the weblog: 


Visitor 


Publish Weblog 



Search Content 


Author 


Figure 3. Use case Diagram 

Both visitors and authors want to be able to search. Furthermore, it is not possible 
to search for content that has not yet been published. The “Search Content” use case is 
therefore dependant upon “Publish Weblog”. 

Suppose we decided to employ Google for our searching function. Google 
becomes an actor and the “Search Content” use case is dependent upon Google. 
Google’s task as an actor is to deliver search results. 
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Publish Weblog 


Vlsnor 


* 

‘\* ' k.'‘ 

Search Content 


Author 


'jk 


Google 


Figure 4. Use case Diagram 

By now we have already identified some of the actors involved with our weblog, 
the goals they are trying to achieve and some dependencies between them. We can 
consider this a high-level conceptual architecture of our site, which will be useful when 
making design decisions later. (Cockbum 2001) 

2. The Main Benefit of Use Cases 

The crucial benefit of use cases is the way they encourage a directed method of 
considering project requirements. From the very beginning, we are designing a product 
by concentrating upon the needs and wants of those who will use it. 

As with any foundation, the better our understanding of the use cases, the easier, 
more focused, and more appropriate will be the work that follows. Use cases are the 
context that allows us to easily picture where, within a project’s life, a particular element 
will fit, thus promoting clearer decision-making throughout design and development. 
The purpose of describing use cases is emphatically not to fully specify the exact nature 
of what a new site will contain and how it is to be built. Instead, use cases define goals 
and purpose: the problems we are trying to solve. Establishing these goals lays the 
foundation for the scope that will follow. Additionally: 

• If we simply consider the roles played by the actors and their goals, the 
use-case model can very rapidly emerge. 
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• Use-case diagrams can distill a complex project into a more easily 
comprehensible picture. 

• A well-constructed use-case model can be understood by all the 
stakeholders in a project: developers, managers and clients. It is a 
powerful aid to collaborative development. 

• Use cases ensure that scope is under control from the outset. The 
identification of use cases and their dependencies makes it easy to 
distinguish between core goals that must be satisfied and subsidiary 
enhancements that may be postponed. Scoping in this manner allows for 
better planning and prioritization. 

• There is no consideration toward implementation so use cases can be 
explored without restriction. No assumptions about tools and technologies 
are made, nor should they be. 

Use-case driven development is a mindset, as much as it is a technique. By 
emphasizing the actors and what they wish to achieve, project teams can advance with 
greater confidence and clarity. A solid early foundation of understanding amongst all 
concerned allows more rapid decision-making later on, and encourages a continual focus 
on the project’s true purpose. This is not to say that use cases were the only tools we 
used to create our site. We used several other tools that are described below but it is the 
use case that is the foundation of the requirements portion of the Inception Phase. From a 
complete list of use cases we were able to clearly visualize the requirements and 
functionality of this web site. The use cases proved to be our most valuable tool in 
development due in large part to the unrestricted nature of creating a use case. Our use 
cases became a “wish list” and we later tailored the use cases as we explored capabilities 
within the design stage. 
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III. SYSTEM DEVELOPMENT 


A. OUR APPROACH 

For this project, our team followed the guidelines of the Unified Process but we 
also tailored the process of development as we found appropriate. We were able to 
complete the Inception Phase, the Elaboration Phase, and the Construction Phase. The 
Transition Phase is still ongoing. 

1. Inception Phase 

We documented our work in the Inception Phase with a complete Requirements 
Document which is found in Appendix I. In developing our Requirements Document, we 
initially focused our efforts on developing use cases as described above. The 
Requirements Document includes a flow chart of information paths, use case diagrams, 
use cases, system sequence diagrams, a list of the required options for the home page 
along with a detailed diagram of each selection, and a decision tree to visually display the 
options necessary to choose a uniform display. We were initially uninhibited in our 
initial use case declarations but we later reviewed our use cases and tailored our list based 
on feasibility and time constraints of this project. We then quickly developed the 
boundary use cases and the use case diagrams that are simply a sketch of the actors 
involved in each use case. 

For each use case, we developed a sequence diagram, which is another tool 
associated with the Unified Process. Sequence diagrams “represent the objects 
participating in the interaction horizontally and time vertically.” (Brugee and Dutoit, 
2003) We used the sequence diagrams to detail the viability of our use cases and 
determine whether a system could actually support the functionality described in the use 
case. 

We also relied heavily on flow charts in the Inception Phase. These flow charts 
allowed us to clearly visualize and plan for the various options that would be found in 
this site. This tool proved to be invaluable to us since these charts lead us directly into 
the Elaboration Phase. We were able to map out the log in procedures and, more 
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importantly, we mapped out the home page selections. It is these selections that drove 
the entire design process since this functionality was vitally important to the site and was 
the reason behind the entire concept. 

Throughout the Inception Phase, we found it valuable to constantly remind 
ourselves of the intended audience of this system. This system will be relied on by 
Marines world wide as an accurate source of standards that ensure their compliance with 
the Marine Corps Order. The new system needs to address all aspects currently outlined 
in the regulations, such as proper wearing of the uniform, grooming standards, ribbon and 
medal precedence, civilian attire, PT gear, and optional items for male and female 
officers and enlisted U. S. Marines. This system could also be used by all US civilians 
and military service members to whom the current manual is now relevant. Keeping the 
audience at the forefront through the Inception Phase is vital to scoping the size and 
functionality of the system being developed. 

As stated earlier, our team assumed the role of the client during this project. One 
of our team members is a U. S. Marine so we had an intended user working on the 
development of this system. We still felt it necessary to conduct a user analysis in order 
to attempt to capture the characteristics of our users and to help us narrow the necessary 
functionality. We concluded that the user population would be widely varied in 
education (civilian and professional), computer savvy, age, and cultural background. 
Interaction with the GUI interface to the system needs to be intuitive for the user with a 
high school background and minimal computer skills while simultaneously not alienating 
the more educated user population. Additionally, implementing multimedia suitable and 
appealing for both the young and older users proved arduous. Finally, in order to avoid 
confusion, we needed to be vigilant in our usage of terminology (especially acronyms) 
that is only prevalent in certain cultures. 

The expected users of this system include all members of the U.S. Marine Corps 
as well as any other military members desiring information regarding Marine Corps 
uniforms. Users may also include civilians requiring the same information. The 
expected users will range from Marines with very little military experience to career 
Marines whom have dedicated a lifetime to the Marine Corps and are well versed in the 
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current uniform regulations as well as past versions of the manual. This system must 
satisfy the needs of a Marine who is new to the Marine Corps as well as the veteran. It is 
vital that the information provided be accurate and correct in order to prevent the user 
from wearing a uniform or uniform item against current policy. 

This system needs to incorporate simplicity within its design. The initial design 
will be under the assumption that the user has basic computer operating skills and web 
browsing capabilities. Where applicable, the system should hide system complexity from 
the novice while simultaneously appealing to the expert user. No additional skill sets 
were assessed as being required for successful operation of the system. The majority of 
interaction the user will have with the system will involve “point and click” functionality. 

The following are major system operations derived from the use cases found in 
Appendix I. 

• Prospective user should be able to create a user name and password to 
access the site and set account information. 

• Prospective user should be able to log-in to the system with a user name 
and password or enter the system as a guest. 

• Prospective user should be able to update account information that is 
currently stored in the data base. 

• User should be able to search for a uniform authorized for own rank. 

• User should be able to gather information and photos on uniform 
regulations for ranks or genders other than his own. 

• User should be able to access grooming standards for a male or female. 

• User should be able to see awards displayed in order of precedence for 
their own awards or entered awards. 

• User should be able to view regulations for civilian clothes. 

• User should be able to view regulations for Physical Training (PT) gear. 

• User should be able to view regulations for organizational clothing. 

The boundary use cases found in Appendix I identify the necessary set up 
required for initial system functionality. The boundary use cases can be summarized as 
follows: 

• The system must allow an administrator to put a new file into the system. 

• The system must allow an administrator to edit user accounts stored in the 
database. 
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• The system must allow an administrator to add or remove an award from 
the database. 

This system functions as a web server capable of displaying interactive pages to a 
user with containing text as well as images. The web server needs to interact and 
exchange information with a database which holds user account information as well as 
images to be used and displayed by the server at the request of the user. Appendix I 
shows high level sequence diagrams that illustrate the interaction between the user, the 
system and the database for the use cases given. 

2. Elaboration Phase 

The main documentation that captures our work during the Elaboration Phase is 
the Software Design Specification found in Appendix II. The purpose of the Software 
Design Specification is to describe the functionality of the Web Based Uniform Manual. 
This document describes the subsystems and modules that form the Graphical User 
Interface, Web Server, and Database. The Software Design Specification provides highly 
detailed technical data, system information, and other relevant information on the Web 
Based Uniform Manual. This document includes an architecture diagram, a design class 
diagram, interaction diagrams, state diagrams, and a glossary. 

Of course the goal of any system design is to satisfy the requirements given by a 
client but more than that is to provide a system that will be easily used by the intended 
audience. What good is a system that meets all of the functional requirements if it is too 
difficult for anyone to use? Our goal for this project was no different. The guide will be 
implemented using primarily visual aides and follow the practices of good Macro/Micro 
HCI Design. The aim was to provide the needed information to the user in an easy to use 
GUI interface that requires minimal “mouse clicks” to retrieve the desired information. 
The guide will also provide the user with alternative text from the Marine Corps Order 
P1020.34G dealing with the specific uniform in question. The end result is an easy to use 
research tool that may be utilized by members of the United States Marine Corps to 
ensure that their uniform is within regulations. 

Our Web Based Uniform Regulations Manual is organized into a three-tier closed 
architecture composed of a presentation layer, application logic layer (domain), and 
storage/network layer (services). The purpose of this organization is to promote reuse, 
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support distributed processing, and allow parallel team development. Also, by building 
each layer only in terms of each immediate lower layer, this design will reduce 
dependencies between each layer enabling the system to be combined with other 
hardware/software platforms with minimal rewriting of single layers. 

The System Architecture decomposes the Web Based Uniform Regulations 
Manual system into subsystems by vertical layers and horizontal partitions. The 
presentation, domain, and service top layers are represented by the common graphical 
user interface, CTF Infrastructure, and Computer Website services subsystems 
respectively. Figure 5 illustrates the organization of subsystem layers and partitions 
within the Web Based Uniform Regulations Manual System Architecture. 
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Presentation Layer 



Figure 5. System Architecture 


A web browser will function as the client interface. Its sole purpose is the display 
of the Web server generated HTML pages. To create a platform independent experience 
the page layout will be controlled by Cascading Style Sheets. These style sheets, once 
cached by the browser, will also account for faster webpage loading. All content creation 
will be done by server side PHP scripting, again contributing to a browser independent 
display without the need for client side browser plug-ins (like Java script), thus speeding 
up the page load time and avoiding safety critical scripting on the client computer. This 
will also allow handheld devices, which are not always equipped with scripting capable 
browser, to load and display the interface pages. 
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Figure 6. System Context Diagram 

The middle tier is divided in two units with different functions, an intermediate 
layer (web server) implemented in a scripting language (PHP). This layer receives 
requests from the Internet clients and generates html using the services provided by the 
storage/infrastructure layer. This additional layer provides isolation between the 
application layout and the application logic. 

This system is designed to reside on an Apache Web Server. The Apache Web 
Server has several advantages; it is extremely powerful, modular, flexible, highly 
configurable, and extensible. It is freely available through open source which means that 
its source code is examined constantly by numerous users. This constant examination by 
outsiders makes it substantially more reliable than any commercial software product that 
can only rely on the scrutiny of a closed list of employees. Apache currently runs on 
approx. 68-70% of all web servers worldwide making it the #1 choice of web servers 
since 1996 (Appu, 2002). This makes it the most secure web server worldwide. The 
information on this site needs to be in complete compliance with Marine Corps Order 
P1020.34G. Any deviations from this standard render this site useless. The threat of 
hackers is always present when dealing with the web based systems. If any user can 
break through and change any of the information on our website, it will sacrifice the 
integrity of the information posted. Once the information is found to be inaccurate, it 
will render our system unreliable and discourage its use. Apache provides security- 
related configuration directives enabling administrators to tighten the security (Appu, 
2002 ): 

• User / Group: Defines user/group Apache should run as 

• LimitRequestBody: Restrict total size of HTTP request body sent from a 
client 

• LimitRequestFields: Limit number of HTTP request header fields that will 
be accepted from the client 
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• LimitRequestFieldSize: Limit size of the HTTP request header allowed 
from the client 

• LimitRequestLine: Limits overall size of the HTTP request line that will 
be accepted 

• Listen: Defines the IP addresses and ports the server listens on 

• ServerTokens: Server HTTP response header 

• ServerSignature: Content of footer available on server-generated 
documents 

• SSLEngine: Toggle usage of SSL/TLS protocol engine 

• UserDir: Indicates the location of user-specific directories 

The basic design philosophy that we followed was to create four complete and 
separate sites that can actually completely stand alone and have a common link from the 
login page as shown in Figure 7. 



Figure 7. Overarching Design 


This type of architecture allowed us to extensively test while developing the site. 
We first created the Male Officer “site” in its entirety and tested this module. Then we 
created the login page and developed its functionality. Once the login page was linked to 
the Male Officer “site”, we exhaustively tested this smaller system and developed it 
completely, as described in Chapter 5 of this document. Then it was a simple duplication 
of the Male Officer “site” in order to create the Female Officer “site”, the Male Enlisted 
“site”, and the Female Enlisted “site” (allowing for the subtle nuances of each 
subcategory). The final step in architecture design was to link all four subcategories to 
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each index page. For example, if a user is currently in the Male Officer “site” and he 
desires to look at female enlisted uniforms, he can quickly access the index page of the 
Female Enlisted “site” and navigate through that “site”. 

All four subcategories share the same file names as shown in Figure 7. This 
allows for the quick creation of the remaining subcategories after the first one was 
created. This type of file naming pattern is attainable since all ranks and genders within 
the USMC must follow the same manual. Also all ranks and genders within the USMC 
have the same uniform names but the style of the uniform varies between ranks and 
gender. A clear and concise file structure is imperative for construction of this site and to 
ensure maintainability. All files needed to be arranged in a manner that was easy to 
follow and was unambiguous since this system will not be maintained by the original 
design team. 

All files are placed in one of four substructures that are referenced from a main 
index page. As mentioned above, the files are broken up into four main categories; male 
officer, male enlisted, female officer, female enlisted. Figure 8 shows the file structure 
for male officers. This structure is simply repeated for all other categories. 
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a Q Awards 

o My_Awards 
O New Folder 
id) Civilian_Clothes 
id) Grooming_Standards 
a Musical_Units 

o D_and_B_hjll_dress_female 
Q Full_Dress_Asst_Dir 
Q Full_Dress_Ceremonial 
id) Full_Dress_Concert 
O Full_Dress_Director 
o Full_Dress_Drum_Maj 
id) Full_Dress_Summer 
id) New Folder 
id) Special_Full_Dress_Female 
id) Special_Full_Dress_Male 


a id) Organizational 
id) BRASSARDS 
Id) BREASTCORDS 
id) CAMPAIGN_HAT 
id) FIELD_COAT 
Id) FLIGHT_CLOTHING 
id) FOOD_SERVICE_CLOTHING 
Id) HEADGEAR_SPECIAL 
id) HONOR_GUARD_EQUIPMENT 
Id) MARINE_SECURITY_GUARDS 
Id) MILITARY_POLICE_EQUIPMENT 
id) MOURNING_BAND 
Id) PHYSICAL_TRAINING_CLOTHING 
id) SAM_BROWNE_BELT 
id) SELECTED_ENLISTED 
id) SERVICE_BELT 
Id) SHORE_PARTY_DESIGNATION 
Id) SWORD_AND_SCABBARD_NCO 
id) 5W0RD_M0URNING_KN0T 
Id) TROUSERS_SKIRT5LACK5_WHITE 
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ICj) PT_Gear 
Ir^l Rank_Insignia 
C Shared_Photos 
B & Uniforms 
B |£) Blue_Dress 

Q Blue_Dress_A 
tj) Blue_Dress_B 
Infi Blue_Dress_C 
Infl Blue_Dress_D 
|^| Shared_Photos 
B C Blue_White_Dress 

o Blue_White_Dress_A 
o Blue_White_Dress_B 
O Shared_Photos 
B |£| Evening_Dress 

Cl Detailed_Sections 
C Evening_Dress_A 
Q Evening_Dress_B 
IrTi Shared_Photos 
Q Optional_Items 
B S Service 

S) Service_A 
C Service_B 
C Service_C 
|^| Shared_Photos 
Q Shared_Photos 
B £) Utility 

Dessert 
Shared_Photos 
o Woodland 
Shared_Photos 

Figure 8. File Structure 


3. Construction Phase 

The construction phase is where we actually created the code and built the site. 
Part of the code is provided in Appendix V. The whole site is coded in XHTML 1.0 
Transitional, CSS 2.1 and PHP 5. The combination of XHTML, CSS and PHP was 
chosen by us to allow for an easy maintenance of the website and represents the present 
time open source standard for websites that include server side scripting. 

A main CSS style sheet controls the complete layout of every page. So global 
changes to adapt the layout to varying requirements are simple and only call for a change 
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in one place, the main CSS style sheet. To allow style and layout changes to single pages, 
each page has been given its own style sheet as well. 

PHP was used mainly to assemble each page by using include statements 
combined with validation code. The content of each page is separated in multiple files 
that contain the textual information, the navigation bars and buttons and the images used 
on that page. This design was chosen to allow a simple implementation of changes in the 
original uniform manual in the corresponding web page. If for example a text of a page is 
changed the manger of the site only needs to open the corresponding file containing the 
text to be changed. By structuring the pages of the online manual this way the possibility 
of unintentional changes to the website are minimized. Although the text documents are 
HTML pages, they contain only the most necessary markup for structuring the text. This 
could have been done in a plain text file. The simple HTML markup however allows for 
color coded syntax highlighting in almost every text editor and so increases the 
readability of the text. The basic structure of the HTML document like head or body tags 
is provided and needed only in the main file that contains the include statements. 

In the case that a text containing document or an image is removed from the file 
structure the validation code co-located with the include statements in the PHP part of the 
page will ensure that the page is still displayed without any problems or errors. This 
allows the site manager to remove unwanted or outdated contents without changes in the 
code of the main page. The generic naming of the files also allows for an easy 
replacement of pages, documents or pictures. 

The top and left navigation bars are global and exist only in one place for each of 
the four main structures. This again allows for simple global changes should additional 
links be required or target URL’s change. 

Although research into client side scripting technologies like Ajax (McLaughlin, 
2006) were done, server side scripting was chosen to allow even the weakest or highly 
restricted client hardware access to the site. Restrictions like low computing power or 
disabling of JavaScript for security reasons have no effect. The only thing the client 
hardware needs to provide is some kind of web browser that is capable of displaying 
XHTML files. The combination with CSS then allows a styling adapted for different 
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devices. At the present time styling for mobile devices and print output are possible. This 
styling has not been implemented by us at the present time and remains at the discretion 
of the Marine Corps. 

4. Transition Phase 

During the Transition Phase we conducted extensive testing which is described in 
Chapter 5 of this document. This is also the phase where the system is deployed to the 
intended user, however, as of the writing of this document, we have yet to complete this 
portion. It is our intention to travel to Headquarters Marine Corps in Quantico, VA to 
present this project. It is our hope that the Marine Corps will find our site valuable and 
will host the site on its web servers. This is a secondary goal of this thesis, with the 
primary goal being to study how the Unified Process could be implemented in web site 
design. The success of our site within the Marine Corps is irrelevant to this thesis and is 
not covered here. 

B. RISK ANALYSIS 

1. Risk Management Plan 

Our risk management plan can be summed up in the following: 

• Identify Risk 

• Assess Risk 

• Assess Likelihood 

• Determine Risk Mitigation 

• Assess Final Risk Cost 

• Adjust Project 

To identify risk our team did some simple brainstorming. We simply tried to 
consider all risk scenarios and tried to pinpoint the risk involved. We researched 
available literature and based a lot of it on past personal experience. We immediately 
filtered those risks that were highly improbable. This is the area of risk assessment that 
can get completely out of hand. There is a seemingly infinite amount of risk in 
everything we do. There could be a lightning strike that could injure one of our team 
members down which would have a major consequence on this project but the likelihood 
is so minimal that it is not addressed. This philosophy prevented our team from getting 
too far off course with risks that were not going to affect this project. 
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To assess risk we looked at all of our listed risks and gave each risk a value. We 
used the following scale found in (Hall, 1998): 

• Very Low: Risk is an inconvenience without serious impact 

• Low: Risk has a minor impact to the process or product 

• Moderate: Risk may disrupt the process or degrade the product 

• High: Risk seriously disrupts or degrades a major part of the project 

• Very High: Risk threatens failure of the project 

It is crucial to any risk analysis to stay focused on the task at hand and not get 
ahead of the management plan. It is always tempting to disregard some risks because the 
mitigation plan is intuitive and easy to implement. However, the assessment stage is not 
the time to introduce mitigation but rather to stay focused on assessing the risk. For 
example, with this project we identified the security of our site as a risk. If someone 
broke into our site they could make unauthorized changes and disrupt the accuracy of the 
information provided. Displaying inaccurate information would make our site 
completely useless. Our team was quick to realize that our site would be placed on the 
official USMC web page which would make this type of attack unlikely. Although our 
site would not exist without the protection of the USMC server, this fact needed to be 
overlooked when assessing this particular risk. We had to assume the worst and simply 
assess the risk as if we were going to place our site on an open web server. The 
mitigation of placing it on a secure server would come later and should not be considered 
here. 

To assess likelihood of occurrence for each risk we used the following scale (Hall, 

1998): 

• Chances are slight, highly unlikely, almost no chance 

• Little chance, probability not unlikely 

• Improbable, we doubt, better than even 

• We believe, probably, likely 

• Very good chance, highly likely, almost certainty 

There are several different ways to assess the likelihood of occurrence of a risk. 
The best and most substantial involve metrics and using probability and statistics. This is 
best achieved on a project that already has a great deal of data to go with it. There is 
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usually a history of past risk assessments that can be applied to the current evaluation. In 
our case here we did not have such historical data to fall back on so we had to use our 
best estimation based on our own experiences. 

The risk mitigation for our project came much the same way the risk 
identification came about. Our team simply brainstormed and developed what we felt 
would be possible mitigations for the risks we identified. Assuming the mitigation plan 
was implemented, we used the same scale as before to again determine the final cost of 
each risk. The mitigation will only have an effect on the likelihood and not the 
assessment. This is an important point to keep in mind. Identified risk that truly exists 
will always be risks to a project. The mitigation will only decrease their likelihood of 
occurrence but it will not diminish the risk. For example, if the risk of information 
security is identified and assessed to have a score of 5 on the assessment scale above. 
That means that we feel that a breach in the security of this system will have a very high 
risk and threatens failure of the project. We may believe that the likelihood deserves a 4 
on our scale which means it is likely to occur if we do nothing to mitigate its occurrence. 
After putting in some measure to mitigate this risk we can significantly decrease the 
likelihood that this breach in security can occur however we have done nothing to lower 
the assessment score of a 5 on our scale. The risk of a breach in security remains high 
but we have just reduced the possibility of occurrence down to an acceptable level. This 
is the goal or our risk management plan. 

After implementing our mitigation plan, we determine a final risk cost for the 
identified risk. This cost is the final probability that the risk will still occur. It is our goal 
to reduce all risk down to an acceptable level. The idea of an acceptable level is 
somewhat objective since risk acceptance can be so varied based on personal beliefs and 
the project’s mission. The fact still remains that some risk will always remain and not all 
risks can be reduced down into an acceptable range. In these cases a decision needs to be 
made. The project plan can be adjusted based on the potential risk or the level of risk can 
be simply accepted. This decision rests with the project manager or the client but some 
level of risk will always exist. 
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2. Risk Analysis for Our Thesis 

Our team gathered and did some brainstorming and identified several risks. We 
immediately discarded some of our identified risks based on the extremely low l ik elihood 
of occurrence. We settled on the following risks: 

1. Finishing on time - we planned to finish this website by July 2006. There 
was a risk that we could get behind schedule and not complete this project 
on time. 

2. Staying within budget - our thesis advisor gave us an allotted amount of 
funds that can be spent on a thesis. We will require TAD funds for some 
traveling to Quantico, VA. There is a risk that we could go over our 
budget. 

3. Information Accuracy - the Marine Corps Uniform Regulations are 
constantly changing. This site needs to be updated as changes to the 
Uniform Regulations are approved and passed on to the fleet. We run the 
risk of having inaccurate information on our web-site if it is not updated 
appropriately. 

4. Security of Site - the threat of hackers is always present when dealing 
with the internet. We have a risk of susceptibility to hacker attacks. If 
any user can break through and change any of the information on our 
website, it will sacrifice the integrity of the information posted. The 
information on this site needs to be in complete compliance with the 
Official Uniform Regulations Manual. Any deviations from this standard 
render this site useless. 

5. Usability/Acceptance - We feel our biggest risk is that our intended 
audience, the Marines, will not use our website. If the information is not 
presented in a user intuitive and aesthetically pleasing manner, it will not 
be used. 

We gave our risks the following assessment values: 

1. Finishing on time: 3 Moderate: Risk may disrupt the process or degrade 
the product 

2. Staying within budget: 2 Low: Risk has a minor impact to the process or 
product 

3. Information Accuracy: 4 High: Risk seriously disrupts or degrades a 
major part of the project 

4. Security of Site: 4 High: Risk seriously disrupts or degrades a major part 
of the project 

5. Usability/Acceptance: 5 Very High: Risk threatens failure of the project 
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We gave our risks the following likelihood value: 

1. Finishing on time: 3 Improbable, we doubt, better than even 

2. Staying within budget: 3 Improbable, we doubt, better than even 

3. Information Accuracy: 5 Very good chance, highly likely, almost certainty 

4. Security of Site: 5 Very good chance, highly likely, almost certainty 

5. Usability/Acceptance: 4 We believe, probably, likely 
Our risk mitigation plan is as follows: 

1. Develop a detailed timeline and stay on track. Timeline should be realistic 
enough to be managed but not have unnecessary delays. 

2. We need to forecast all TAD costs. There is no cost to develop the site or 
use the server but there is cost for travel to Quantico VA. 

3. We will pass this project off to the Marine Corps once we are done. It will 
be incumbent on them to keep the site up to date with the latest changes. 
We will need to ensure that the site’s administrator is trained on this site. 
If this site is accepted as an official USMC website, it will be kept up to 
date since Marines will be using it as an official reference. 

4. If we first assume that this site is placed on an open server, we feel it is 
highly likely that someone will try and succeed at breaking into the site 
and make malicious changes. Since we are going to put it in the USMC 
web server, we are certain of its security. This will provide the protection 
we need to prevent unauthorized changes. 

5. We need to follow good HCI design and methods as illustrated in our HCI 
checklist. The principles of Human Computer Interaction will be fully 
explored with this thesis. The design will be IAW the principles of HCI 
and will support quick links and menu driven systems that will allow all 
relevant information to be displayed or hidden as the user requires. 

After the implementing our mitigation plan we feel that that we have substantially 
reduced our risks and we continued our development with a much clearer direction 
avoiding some of the pitfalls that could have hindered the process. 

C. CONFIGURATION MANAGEMENT 

According to Wikipedia, Configuration Management is defined as “The control of 
changes—including the recording thereof—that are made to the hardware, software, 
firmware, and documentation throughout the system life cycle.” Configuration 
Management is the key to managing and controlling the highly complex software projects 
being developed today. Configuration Management tools have developed from simple 

version-control systems targeted at individual developers into systems capable of 
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managing developments by large teams operating at multiple sites around the world. In 
an uncontrolled site where multiple authors have access to edit and contribute, the 
potential for conflict and problems arise. One author may spend an entire day working 
on a particular file in the project and he may think that his changes are final. However, 
after these changes are made, another developer who works at home after hours, or in 
another office, may spend the night uploading their own newly revised version of the 
same file, completely overwriting the work of the previous author with no way to get it 
back. This is disastrous for project development and could be avoided with proper, and 
simple, configuration management tools. (Haas, 2002) 

For this project, we developed our own tool for Configuration Management. 
Although our team was co-located during the development of this site, we did most of the 
work on the site at different locations, our homes. We may have been able to develop 
this site without developing this tool but for the purposes of this academic work, we felt it 
necessary to become familiar with Configuration Management and implement it in the 
development of this site. In keeping with the spirit of this project and our goal to become 
familiar with the software development process, we realized that Configuration 
Management is a crucial part of developing software so this type of experience would 
greatly benefit us as future software developers. 

For our project we created our own Configuration Management tool that allowed 
us to individually work on the thesis but still provide version control and instant updates. 
We created a web based tool that is shown in Figure 9. Shown in Figure 9 is the main 
page of the Configuration Management site which we used throughout this project. In 
the center of the page we included a text area that details our timeline and any notes that 
we felt were necessary. Both team members had access to upload files and messages to 
the site which allowed us to communicate with each other while maintaining remote 
locations. This proved to be invaluable in the development of this project. On the left 
side of the page, we linked all versions of current documents that were required. We 
were able to assign tasks for any document to individual team members and that member 
would then upload the document to this site for other members to view. This was the 
strategy for using this tool and it follows the practices of Configuration Management as 
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described above. This also made it convenient for our advisors to view our progress and 
keep up with the latest versions of our documents and our uniform manual web site due 
to the tool being based on the web. 


We also used the left side of the page to hold our documentation for the thesis 
write up. As we individually worked on chapters we could then upload them to the 
Configuration Management site and have them viewed and edited. The right side of the 
page was reserved for any links that we felt were related to our work. 


Although the Configuration Management tool that we created for this project was 
quite simple, it did emphasize the importance of its use. We may have been able to 
develop this project without the use of such a tool since the team members were all 
centrally located here at NPS, but for our purposes in the academic environment the tool 
was invaluable. It provided us the convenience to work independently but at that same 
time it allowed us the assurance that our work was not being duplicated and would be 
seen by other team members. 


Thwis workflow 

Lest modfed: July 25, 2006 11:15:48 PM COT. 

1. Acceptance them proposal: Oct. 20 

2. Start developing USE Cases (M.ke): Od. 30 

3. Start Server/Oetabase research (Canten): Oct. 20 

4. Research into XMl/XMTMl and CSS (Carsten): Nov. $ 

5. Prototype 2 development start: Dec. 10 

6. Server security research result upload; Jan. 11 

7. upload Use Cases final(M.ka): Jan. 16 

8. Upload Use Cases Final (Mike): Jan 19 

9. Start Development of User Databa»e<php/MySQL>: 

10. Upload RAD (Mike/Carstcn): Jan 29 

11. Installed Prototype 2.1(Carsten); Feb 1 


UtMMLaBM 

home aerver - might not be onleie el the hme 


Figure 9. Configuration Management Website 



document dcmvSosd 

folder 

a 

them p~po»jJ<pdf 1 

• 

- 4*vMm 

of UfeouKpdD 

* 

IWiH - PkmaUIim 
)■*-■ I4(ppt) 

• 

uniform ruguUtivn 

• 

old Clf protect Mm 

• 

KnV Analyse* 

• 

Security Aulpn 

• 

UVt <et#% (Jam IS) 

• 

UM Case* (word 

document) 

• 

UST cm** diagram* 
(Jaa 10) 

• 

RAD 

• 

RAO (word document) 

• 

SOS (word document) 

• 

old Ml US project 
(Prototype 1.0) 

• 

Prototype 2.0a (le+e») 

• 

Prototype 2.t 

• 

Prototype J.O 

a 

Final 

• 

Chapter 1 

e 

Chapter 2 

• 

Chapter 3 

• 

Chapter 4 

• 

Chapter 5 

• 

Appendix 


Fdes, nformatiorvs 

and resources are 
available as POF. 
TXT or JPG files. 

Downloadable 
software »s 
freeware and 
contains the 
necessary beenses. 

• Admin paqe 
(restricted) 


EXTERNAL LINKS: 


Ribbons (not 
official) 

Ribbon 

checker 

USB mini 

none 
(Acacbe 
Hf IP. 
MySQL 
PUP. Perl) 


33 





D. EVOLUTION AND REUSE 

This system has been designed in order to allow for easy maintenance. The 
designers of this system will not be responsible for any future maintenance of this system 
so it was our intention to build this site and turn all files over to Headquarters Marine 
Corps for implementation. Our design goal was to allow this site to be usable for many 
years to come within the Marie Corps. This can only be achieved if the site is easily 
maintainable and files can be edited or deleted as the MCO changes. In order to achieve 
the desired maintainability, the design must adhere to the following: 

1. Reliability 

The reliability of this system will be dependent on the stability of the code and the 
capacity for system upgrades. The design of this system has been done with the goal of 
system reliability in mind. 

2. Efficiency 

This system must be designed to maximize the efficiency of the code. This has 
been done by inhibiting overloading and preventing unnecessary parts of the code. All 
written code has been thoroughly scrubbed for gratuitous code or files. 

3. Understandability 

This will be a key aspect to maintaining this site. The documentation provided in 
the System Design Specification as well as the structure of the files will help future 
maintainers to understand the site and assist in implementing any changes. It is unknown 
as to the technical expertise and experience of the future maintainer of this site so full 
documentation is critical. 

4. Measurability 

Software metrics can be used to estimate the project budget and schedule, 
evaluate individual productivity and quality, evaluate project productivity and quality, 
and evaluate the system quality. 

The design specifications for this system call for the design of a web based 
uniform manual for the United States Marine Corps. However, the same need can be 
paralleled to any service within the Department of Defense or any international military 
organization. This system has been designed with the concept of reuse in mind. The 
system developed here can be easily transferred into any other service branch with a file 
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structure that is generic enough to allow for the input of any uniform type and a system 
structure that can support any similar specification. 

E. HUMAN COMPUTER INTERACTION 

To facilitate an efficient system use and to guarantee user acceptance we needed a 
tool, a guideline, based on HCI principles. This guideline became a set of eleven 
categories for the visual and usability design. After reviewing several references, we 
developed the following categories that we feel are essential to successful web design: 

1. Category 1: Simplicity 

Simplicity provides the means by which the web page aims to keep the basic 
utility of the interface easy to use, and offer facilities which are of a clear value to the 
military member. The interface should be intuitive and there should be no question as to 
how to use this manual. We designed our site by mirroring the official USMC web page 
found at www.USMC.mil . The basic outline of this site is one that is well recognized by 
all Marines and it provided us with a simple template to follow. 

2. Category 2: Consistency 

The user should feel that he or she is in control and that the system is responding 
to his or her actions accordingly. Users should have control over the amount of 
information they receive at different points of the interaction. During the interaction, the 
web page should have a common look and presentation that is presentable and 
professional. As explained, the manual is broken up into four main categories; male 
officer, male enlisted, female officer, female enlisted. During exploration of this manual, 
each category is easily identified and allows for ease of presence within this site. 

3. Category 3: Control 

Control actions initiated by the user should receive the appropriate responses. 
Error and control messages should generate the same responses throughout this site. We 
allowed for the user to maintain complete control of the navigation and access of this site. 
We ensure that every link remains active and all areas of the site are easily navigable. 

4. Category 4: Shortcuts and Customization 

The web page should present mechanisms for users to customize settings to speed 
frequency of use by users. We accomplish this by allowing the main navigation bars to 
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be constantly visible and accessible by the user. This allows the user to determine his 
own outcome and retrieve his own desired information. 

5. Category 5: Screen Layout 

The screen layout should give an appearance of clarity with the proper use of 
white space to separate items. Items should be presented in a balanced fashion, and not 
distort during screen resolution change. This shall be achieved by the use of a “liquid 
design”. This “liquid design” guarantees that most or all functions and information are 
visible on all common PC monitor types and sizes. Additionally, control maneuvers 
should be reachable without scrolling extensively. 

6. Category 6: Feedback 

Appropriate feedback before, during, and after interaction is essential to proper 
HCI. Prompts and directions should be provided to the user at all times. The user should 
never be left in a state of question. 

7. Category 7: Error Handling 

There shall be no means of deleting or changing information. This action will 
allow the user freedom of experimentation without degradation of the information 
presented on this site. This will ensure error handling is at a minimum in regards to 
development of this site. 

8. Category 8: Efficiency 

All accessible elements of the web page are generated in a timely manner. To 
ensure an independence from the client device (and thereby allowing every web enabled 
client device to use this manual) all necessary data processing and code generation will 
be done by the server side. The information provided within this site is in conjunction 
with the latest regulation regarding the specific uniform in question. In an effort to speed 
efficiency, a “SEARCH” feature should also be implemented. The added feature will 
allow expert users extended usability of this manual. 

9. Category 9: Help Facilities 

The web page will provide a mechanism to report problems or errors. Additional 
help facilities regarding military uniform regulations will also be provided. The current 
version of our site does not include a “help” function but it could be implemented if 
required by the Marine Corps. 
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10. Category 10: Navigation 

Navigation within the web presence should be easily achieved with minimal 
“clicks” or drop down menus to achieve a desired result. We feel that this is clearly 
demonstrated in our site. We focused intently on providing the required information in 
the most expeditious manner. The written uniform regulation manual contains an 
enormous amount of information that is extremely difficult to comprehend. One of our 
primary goals was to allow easy navigation and we feel like we accomplished this with 
this site. 

11. Category 11: Objects 

Each major category will have similar index pages and file structures. The 
objects that will be created from the index page as the user completes a search for desired 
information are shown in Figure 10. Generic layouts for other pages are shown in 
Figures 11 and 12. These are not objects as normally recognized in object oriented 
programming, but we refer to them as objects for explanatory purposes. Since this entire 
system is web based, objects are not truly created but rather each selection calls a desired 
page within the web server. 


Navigation Bar 

Home Uniforms Grooming Awards Rank Insignia Civilian Clothes PT Gear Organizational Musical Units 

Member Info 

Male/Female 

Rank 

Main Photo Area 

Contact Info 
Help 

Manual 

Detailed Text from Marine Corps Order P1020.34G MCO 

Links 


Figure 10. Index Page Fayout 
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Home Evening Blue Dress Blue/White Dress Service Utility 

Links 

Main Photo Area 

Detailed Text from Marine Corps Order P1020.34G MCO 


Figure 11. Typical Uniform Page Layout 


Navigation Bar 

Home Evening Blue Dress Blue/White Dress Service Utility 

Optional 

Items 

Main Photo Area 

Detailed 

Sections 


Detailed Text from Marine Corps Order P1020.34G MCO 


Figure 12. Typical Uniform Type Page Layout 
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IV. FORMAL TESTING 


A. INTRODUCTION 

Our most valuable learning point throughout our entire thesis work is the 
importance of testing when developing software. The strict Unified Process that we 
mirrored in this web site development calls for a formal testing phase consistent with the 
iterative process. We realized early on the value of proper and in-depth testing in the 
overall success of our system. We did not want to fall into the trap of not leaving enough 
time for solid testing and we did not want to leave testing as an after-thought. We built 
into our timeline for the development of this system plenty of room for a thorough testing 
phase to include the time needed to implement the changes learned from our testing and 
then re-testing the site with those changes. What we did not fully realize was that testing 
of a system is not just limited to the formal testing phase. 

Throughout the development process of this system, we have been conducting 
“informal'’ testing. There are many levels of testing that a system goes through while it is 
being developed. During the inception phase, we tested the soundness of the general idea 
and scheme that we envisioned for this system. Figure 13 shows our original flow chart 
from our Requirements Document that shows the flow of information as we planned in 
the inception phase. We devoted a lot of time in developing this flow chart because we 
knew that it would be the foundation to the entire development process. We conducted 
our own test and evaluation of our flow chart just amongst our development team which 
proved to be invaluable to allowing us to fully understand our plan for information flow 
and it clarified our vision of the entire layout of our system. 


39 





yes 



Figure 13. Flow chart 


We used several tools for this type of “informal” testing including flow charts and 
prototypes but we also relied on basic trial and error as we designed the site. We 
constantly had a local server running on the computer we used to program the design and 
we simply would view pages as we created or changed them for instant feedback. This 
type of on-demand testing along with other informal testing methods proved extremely 
important in the overall development. We set our own standard for this system and we 
did not move forward until we were satisfied with the design at that point. As we moved 
into the formal testing phase, we were much more confident that our system would test 
well with our subjects because it had already passed our own testing standards. This 
“informal” testing was much more ad-hoc and specified as compared to the formal testing 
but it saved us a tremendous amount of time in the overall process. 
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For our formal testing phase we used a usability lab provided by Dr. Ciavarelli. 
The lab consisted of two lap top computers, three cameras, and a voice recorder. The test 
computer was used by our subjects and we used the observation computer to monitor and 
run the tests. The test computer was loaded with a local server which housed our entire 
site. One camera was placed at eye level to record the test subject’s eye movement while 
looking at our site. The second camera was positioned to record the subject’s hands on 
the keyboard to record keystrokes and mouse movement. The third camera was set to 
capture the profile view of the subject in order to capture head movement. We used the 
voice recorder to allow the subject to orally detail their thoughts and critiques and to 
allow instant feedback. We felt this was much more effective than having the subject go 
through the site and then write down their comments afterward. Getting the instant voice 
recording prevents the problem of subjects having to recall their thoughts after the test is 
completed and avoids the nuisance of having to write down the information. Oral 
feedback allows the subjects to speak freely and openly and they are more likely to 
provide detailed comments than if they had to write their thoughts down. We did have 
the subjects complete a survey as found in Appendix IV but this was a short concise 
survey that was simply used to consolidate the test results from each subject. The voice 
recordings were used to provide detailed information that we could go back to and make 
the changes as suggested. 

B. TEST 1 

Our first test was conducted with five subjects all of which were male Marine 
officers currently enrolled in the Computer Science curriculum at the Naval Postgraduate 
School. These subjects had between 10 to 17 years of experience in the Marine Corps 
and all possessed high levels of technical skills. They were all very familiar with the 
current Marine Corps Uniform Manual and they were all familiar with our project 
through informal conversations with our team while we were developing this system. All 
of the subjects were hand selected by our team because of these qualifications. We knew 
this was a specialized group for testing and they would provide uniquely tailored 
responses and feedback. Since this was our first attempt at testing this system in a formal 
setting, we wanted to have a controlled environment with a group of selected subjects 
that had a high level of familiarity in order to validate our own evaluation of this site. 
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Our team felt that the site was well formed and very close to a final product before we 
began testing but we needed to corroborate this with our subjects. 

The usability lab was set up as described above with two computers, three 
cameras, and a voice recorder. The subjects were asked to follow a written scenario 
(Appendix IV) provided by our team. The scenario was intended to provide a common 
baseline in order for a sound comparison to be done on all five subjects. The questions 
on this scenario asked the subjects to find various uniform requirements and we 
attempted to derive questions that users may ask of this system. The actual answers to 
these questions were not as important as simply giving the subjects some direction so 
they would have to navigate through a large portion of the site. We felt that if we just 
had our subjects browse our site as they wished, they may not thoroughly navigate the 
site and they would not be able to provide us useful feedback. All five subjects gave us 
instant oral feedback and they all completed our survey for a written record of the test. 
These completed surveys are provided in Appendix IV. 

This first round of formal testing proved to be quite successful. We learned that, 
overall, our web site was progressing as our team had assessed. The HCI design 
principles described in Chapter 3 of this document that we attempted to follow showed an 
initial successful implementation. The subjects gave us positive feed back on the overall 
navigation of the site and the layout of the pages to include color and font. We designed 
our site to be consistent in structure and aesthetics with other Marine Corps sites that are 
currently available on the web. Some of the subjects immediately commented on that 
fact and stated that they felt like they recognized the layout and instantly felt comfortable 
with the structure. All of the subjects suggested that we implement a “search” function to 
allow a user to more quickly find desired information. We agreed with this assessment 
but we will leave the implementation to the Marine Corps. We received several other 
suggestions for some minor changes that we were able to quickly implement due to the 
simple file structure that was used when designing this site. 

A very important point that we learned during this initial phase of testing was that 
we were able to test our testing procedures themselves. In this instance, both of our team 
members sat side by side with the subjects as they were testing the site. This made it 
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very tempting for our team to steer the subjects around the site and offer suggestions 
while navigating. We also found ourselves explaining away some of the critiques being 
offered by the subjects. Of course, this type of input skews the results of the testing and 
makes it difficult for subjects to objectively evaluate the site. The usability lab has the 
capability to conduct remote testing with the observer computer placed in a separate 
location from the subject. We will implement this in our next phase of testing to avoid 
the temptation of helping the subjects with using the site. The subjects did find that the 
scenario driven questions did prove to be very useful in keeping them moving within the 
site. This was only successful by having the subjects speak aloud while they were 
attempting to answer the questions provided and they felt free to make any comments 
while searching. The running dialogue proved to be the most useful information 
provided during testing. The subjects were encouraged to speak freely, regardless of how 
minor there critiques seemed. Some suggestions were beyond the scope of this project 
but most were implemented. 

C. TEST 2 

For the second round of our testing we focused on testing female Marine officers. 
After receiving the feedback from the male Marine officers during the first test, we felt 
that we could build the entire site and complete all of the navigation for “Male Enlisted”, 
“Female Officer”, and “Female Enlisted”. We felt that the male officer subjects used in 
the first round of testing gave us an adequate representation of that gender and rank so we 
decided that we needed to target other audiences. The female subjects used for testing 
were all female captains but ranged in experience from 10 years to 15 years. Given our 
current location here at NPS, we are limited to the number of female officers from which 
to choose but we felt it crucial to have the site evaluated from a female officer 
perspective. 

Since the site was working in its entirety for this portion of the testing, we needed 
to adjust the scenario provided to the subjects for testing. The scenario is provided in 
Appendix IV. This scenario now required the subjects to navigate the entire site to 
include switching between different ranks and genders. The challenge here is that since 
the site is now four times as big as it was during the first round of testing, it is very 
difficult to have the subjects visit a large portion of the site. We found that it was crucial 
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to keep the testing scenarios short in order to keep the interest level of the subjects high 
and provide valuable feedback. If the testing lasts too long, the subjects tend to lose 
interest and they feel that the testing has now become a burden. This would negatively 
affect the feedback provided by the subjects and would degrade the value of the testing. 
Our challenge then becomes to design a scenario that requires the subjects to navigate 
through as much of the site as possible but complete the testing in a limited time. The 
scenario in Appendix IV was completed in only 20 minutes by the subjects but it does 
drive the users to each rank and gender of the site. 

D. TEST 3 

For our next round of testing we focused on enlisted Marines of both female and 
male gender. At this point we had tested the site on both males and females and we were 
able to make adjustments to the site as necessary. We were confident in the navigation of 
the entire site and we made adjustments to maximize the functionality. Our previous test 
cases hardened our resolve in the usability of the site but we still felt that we needed to 
test for the accuracy of the information provided within the site. Thus far we used strictly 
Marine officers so we shifted our test subjects to enlisted Marines. This proved to be the 
most valuable round of testing completed. 

All of the test subjects were found at the Defense Language Institute at the 
Presidio of Monterey. They were all enlisted Marines, both male and female, ranging in 
rank from Private First Class to Corporal. Their years experience ranged from 4 months 
to 4 years. The most surprising detail of their background was that they had a wide range 
of technical experience. This was unlike the Marine officer subjects of the previous 
rounds of testing who were all Master’s degree students and all possessed a high level of 
technical skill and computer savvy. The enlisted subjects ranged from web designers to 
complete computer novices with very little web surfing experience. We were extremely 
surprised to find such a high level of computer experience with some of the subjects 
conversing at the technical level as to the file structure and design of the site. However, 
we were equally surprised to discover that some of the subjects clearly had a fear of using 
computers and were complete novices to surfing the web and looking at web sites. We 


44 



became quickly convinced that the audience of potential users of this site is much more 
diverse than originally estimated and this round of testing would truly stretch the limits of 
the structure and design of the site. 

After the first few subjects completed their testing, we found it necessary to adjust 
the scenario driven testing. The scenarios provided in Appendix IV proved successful in 
the first two rounds of testing but were actually limiting the subjects during this third 
round of testing. What we found is that the enlisted Marines were too focused on the 
answers to the questions provided and were not providing enough feedback on the site 
itself. It seems that the enlisted Marines are so driven to complete any task given that 
they become blindly focused on completing that task. We tried to emphasize, as we did 
the male and female officers that the scenario is only provided to allow them some 
guidance to navigating the entire site but that it was not intended to be a test of their 
knowledge of the uniform manual. For example, the question “What is the hem size on a 
male enlisted Service Dress C?” was only provided to require the subjects to navigate 
within the male enlisted sub-site. The answer to the question was not at all important, we 
just wanted to provide the subjects some guidance to ensure that they were not just 
aimlessly browsing the site. The enlisted Marines became narrowly focused on 
answering the questions provided and lost sight of our true intentions and the reasoning 
behind the scenario driven testing. 

Our solution to this problem was to have the subjects create 5 questions of their 
own regarding the USMC uniform regulations. They then stated their question out loud 
before proceeding and they were required to find the answer to their question using the 
web site. This actually turned out to be extremely beneficial to the feedback received 
since this was much more closely resembled the way this site would actually be used. 
We anticipate users desiring to gain some information about their own uniforms or about 
a particular rank and gender and then using our site to find the answers. This new testing 
strategy prevented the users from being so narrowly focused on answering our questions 
and allowed them to use the site in a realistic way. This had the positive effect of 
allowing the users to provide us commentary on the site’s design, functionality, and 
accuracy of information, which is the purpose of testing. 
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The feedback provided from this round of testing proved to be invaluable. We 
were able to confidently adjust the site to be usable for a much wider range of users. The 
site became structured to accommodate male Marines as well as female Marines, officers 
and enlisted, and Marines new to the Marine Corps as well as very experienced Marines. 
But the most valuable lesson learned from this round of testing is that our site tested to be 
usable to the computer savvy Marines as well as for the Marines with very limited 
computer expertise. 
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V. CONCLUSION AND FUTURE RESEARCH 


In conclusion we felt that we had a very successful thesis project. We were able 
to accomplish our goals presented in Chapter I while learning much more than we 
initially anticipated. Although it was not our original intent, we have become experts 
with the current Marine Corps uniform regulations manual. This is due to the fact that 
we were required to thoroughly evaluate the current manual in order to implement it in an 
easy to use web site. We needed to be precise on the requirements for wearing all 
uniforms and their accessories in order to provide the users with completely accurate 
information. In our research we found numerous contradictions and errors with the 
current manual that required the attention of the official United States Marine Corps 
Uniform Board. They are responsible for maintaining the regulation and ensuring its 
accuracy. They were pleased that we were attempting to build this site for their use and it 
is with this board that our team will deliver the final product. An example of one such 
discrepancy is there is currently a contradiction in the manual as to the wearing of the 
male all weather coats. In one section of the manual it states that the all weather coat 
could be optionally worn with the Evening Dress uniform. However, that statement is 
contradicted later in the manual with the statement “The AWC may be worn or 
prescribed for wear with the service, dress, and utility uniforms.” There is no mention of 
the Evening Dress uniform. These types of errors were independently corrected with the 
uniform board for accuracy. 

We conclude that following the Unified Process for web development definitely 
led to the successful completion of such a complex web site. Following such a process 
allowed us to focus during the development of this site and it narrowed our center of 
attention to the tasks that allowed us to progress to a finished product. We spent a 
considerable amount of time up front in the Inception Phase and the Elaboration Phase 
which paid off during the Construction Phase. It was very tempting for us to shorten the 
first two stages and dive deeply into constructing the site. The temptation to do this was 
caused by the fact that it is in the Construction Phase that the goal of creating the site is 
attained. We made a concerted effort to follow the guidelines of the process and used the 

tools provided to create a detailed plan with which to follow before writing any code. 

47 



Since this is an iterative process, we did take advantage of the flexibility that allowed us 
to fluctuate between phases and stay within the bounds of the framework. 

Although we are convinced that the Unified Process is an excellent tool to use 
when developing a complex web site, we are still uncertain about the efficiency of using 
such a process. It is difficult to say whether we could have developed this same site in a 
shorter amount of time having used a different process or no process at all. There were 
many factors that drove our schedule and leave some doubt as to the efficiency of the 
process. 

One of our team members did have some prior experience with web development 
and design but nothing as complex as the site for this thesis. His style was much more ad 
hoc with no set process followed as most web designers are inclined to do. Neither one 
of us had any experience with developing software with the Unified Process. We had 
been exposed to the process in theory while here at NPS, but we had no practical 
experience. We found ourselves learning the process while we were actually 
implementing its practices. This fact leads to our doubt as to the time needed to complete 
this site. Were we slowed down because we were not fully comfortable with using the 
Unified Process or were we slowed down because the Unified Process is not designed for 
web site development? We conclude that the former is more accurate rather than the 
latter but future attempts at this same type of development would give a definitive 
answer. 
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B. INTRODUCTION 

1. Purpose 

The purpose of this Requirements Analysis Document (RAD) is to define the 
requirements for the Web Based Uniform Regulations Manual and to present them to the 
customer for review, comment, and validation. The RAD includes a flow chart of 
information paths, Use Case Diagrams, Use Cases, System Sequence Diagrams, a list of 
the required options for the home page along with a detailed diagram of each selection, 
and a decision tree to visually display the options necessary to choose a uniform display. 

2. Background 

The current United States Marine Corps Uniform Regulations, titled Marine 
Corps Order P1020.34G, is available in hard copy or on-line in PDF format only. There 
is not a Graphical User Interface system currently in existence for this information, and in 
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its current form, traversing this document can be a tedious process and time consuming. 
As with most military manuals of its kind, was not written in a user intuitive manner. 

Major issues/concerns with existing manual: 

• The current manual requires multiple pages to be repeatedly referenced 
before being fully understood. 

• Verbiage can be distracting and cause regulations to be misunderstood. 

• It does not provide a “quick reference” for user convenience. 

• Changes to regulations require entire manuals to be generated and 
replaced, leading to older versions with outdated materials still in 
circulation. 

• Not written to be “user intuitive”. 

• Even experienced users can have problems quickly accessing the 
information they require. 

3. Scope and Audience 

The web based manual described in this document will be in strict accordance 
with MCO P1020.34G. This system will be relied on by Marines world wide as an 
accurate source of standards that ensure their compliance with the MCO. The new 
design will be IAW the principles of HCI and will support quick links and menu driven 
systems that will allow all relevant information to be displayed or hidden as the user 
requires. The new system will address all aspects currently outlined in the regulations, 
such as proper wearing of the uniform, grooming standards, ribbon and medal 
precedence, civilian attire, PT gear, and optional items for male and female officers and 
enlisted U. S. Marines. This system could be used by all US civilians and military 
service members to whom the current manual is now relevant. 

4. References 

• Bruegge, Bernd. Object-Oriented Software Engineering. Pearson Prentice 

Hall, Inc. 2004 

• Larman, Craig. Applying UML and Patterns: an introduction to object 
oriented analysis and design and iterative development. Pearson 
Education Inc. 2005. 

• Hall, Elaine M. Managing Risk. Addison - Wesley. 1998. 

C. GENERAL DESCRIPTION 

1. Product Perspective 
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The overall goal of the project will be to create an easy to use web based uniform 
regulation guide in accordance with Marine Corps Order P1020.34G. 

2. Product Function 

The guide will be implemented using primarily visual aides and follow the 
practices of good Macro/Micro HCI Design. The aim will be to provide the needed 
information to the user in an easy to use GUI interface that requires minimal “mouse 
clicks” to retrieve the desired information. The guide will also provide the user with 
alternative text from the current MCO dealing with the specific uniform in question. The 
end result will be an easy to use research tool that may be utilized by military members of 
the United States Marine Corps as well as any person requiring specific uniform 
regulations. 

D. USER ANALYSIS 

The challenge of the project design lies in the fact that the user population is 
widely varied in education (civilian and professional), computer savvy, age, and cultural 
background. Interaction with the GUI interface to the system needs to be intuitive for the 
user with a high school background and minimal computer skills while simultaneously 
not alienating the more educated user population. Additionally, implementing multimedia 
suitable and appealing for both the young and older users will prove arduous. Finally, in 
order to avoid confusion, we must be vigilant in our usage of terminology (especially 
acronyms) that is only prevalent in certain cultures. 

1. User Characteristics 

The expected users of this system include all members of the U.S. Marine Corps 
as well as any other military members desiring information regarding Marine Corps 
uniforms. Users may also include civilians requiring the same information. 

2. User Experience 

The expected users will range from Marines with very little military experience to 
career Marines whom have dedicated a lifetime to the Marine Corps and are well versed 
in the current uniform regulations as well as passed versions of the manual. This system 
must satisfy the needs of a Marine who is new to the Marine Corps as well as the veteran. 
It is vital that the information provided be accurate and correct in order to prevent the 
user from wearing a uniform or uniform item against current policy. 
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3. User Skill Level 

This system will incorporate simplicity within its design. The initial design will 
be under the assumption that the user has basic computer operating skills and web 
browsing capabilities. Where applicable, the system will hide system complexity from 
the novice while simultaneously appealing to the expert user. 

4. Other Needed Skills 

No additional skill sets are assessed as being required for successful operation of 
the system. The majority of interaction the user will have with the system will involve 
“point and click” functionality. 

E. FREQUENCY OF SYSTEM USE 

We envision the system being used on a daily basis by thousands of service 
members and civilians worldwide. However, the average individual user will likely only 
visit the site weekly or biweekly. 

F. ASSUMPTIONS AND DEPENDENCIES 

The following are assumptions and dependencies identified for successful and 
timely completion of the requirements specified herein. 

• No major loss of engineering personnel 

• No major changes in requirements once the documented requirements 
contained within this RAD are approved 

• Availability of test personnel 

• Individuals are familiar with web browsing on their specific systems 

G. SYSTEM FUNCTIONALITIES 

1. System Set-Up 

The Boundary Use Cases shown in Section I identify the necessary set up 
required for initial system functionality. These Boundary Use Cases are further detailed 
with the accompanying sequence diagram in Section K. The Boundary Use Cases can be 
summarized as follows: 

• The system must allow an administrator to put a new file into the system. 

• The system must allow an administrator to edit user accounts stored in the 
database. 
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• The system must allow an administrator to add or remove an award from 
the database. 

2. System Operations 

The following are major system operations derived from the use cases displayed 
in the Use Case Diagram in Section I and described in Section J: 

• Prospective should be able to create a user name and password to access 
the site and set account information. 

• Prospective should be able to log-in to the system with a user name and 
password or enter the system as a guest. 

• Prospective user should be able to update account information that is 
currently stored in the data base. 

• User should be able to search for a uniform authorized for own rank. 

• User should be able to gather information and photos on uniform 
regulations for ranks or genders other than his own. 

• User should be able to access grooming standards for a male or female. 

• User should be able to see awards displayed in order of precedence for 

their own awards or entered awards. 

• User should be able to view regulations for civilian clothes. 

• User should be able to view regulations for Physical Training (PT) gear. 

• User should be able to view regulations for organizational clothing. 

H. SYSTEM ATTRIBUTES 

This system will function as a web server capable of displaying interactive pages 
to a user with containing text as well as images. The web server will need to interact and 
exchange information with a database which will hold user account information as well 
as images to be used and displayed by the server at the request of the user. Section K 
shows high level sequence diagrams that illustrate the interaction between the user, the 
system and the database for the Use Cases given. 

The flow charts found in Section L show the paths that could be selected by the 
user and must be handled by the system. Section M shows the functionality of the home 
page of the system and illustrates all choices required by the user. This system must 
provide the user with all available information found in the MCO and the home page will 
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be the central point of distribution. All selections from the home page spawn several 
different information paths that must be handled by the system. 


I. BOUNDARY REQUIREMENTS 

1. Boundary Use Case Diagram 



Figure 1. Boundary Use Case Diagram 
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2. Boundary Use Cases and Sequence Diagrams 

These boundary use cases describe how the system will be initialized. They 
include the construction of the system files and also all data base input. 


Boundary Use Case: BUC-1 Update System Files 

Primary Actors: System Administrator 

Stakeholders and Interest: 

1. The system administrator has created a file and desires to put the file into the 
system. The system administrator will be required to pass an identification and 
authentication security requirement in order to edit or replace any files. 

Entry conditions: 

1. The system is operational and the file is in the correct format. 

Exit conditions: 

1. The system makes the new file available and the new file is properly linked within 
the website. 

Flow of events: 

1. The system administrator is correctly identified and authenticated, gaining access 
to the system’s file manager. 

2. The system administrator places the desired file into the system’s file structure 
either through the file transfer protocol (FTP) or another available method. 

3. The system administrator logs off of the system, ending the update session. 

4. The system maintains a log of all events during this session. 

Exceptions: 

*. System is unavailable. System shows error message. 

la. The system administrator does not provide an authorized identification or 
password. 

1. The system shows an error message and allows for another 
attempt. 

2. Repeat this for a total of three times before system locks for 30 
minutes. 

a. System updates log of failed attempt. 

b. System allows the update capability to be restored after 30 
minutes. 

2a. The system administrator desires to update or edit an existing file. 

1. The system administrator locates the desired file. 

2. The file is opened and changes are made. 

3. The file is saved in the system with new changes. 

2b. The system administrator desires to delete an existing file. 

1. The system administrator locates the desired file. 
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2 . 

3. 


The file is deleted from the existing files. 
The system updates its file structure. 


System Administrator 


loop 


System 


<- 

- w 

send acceptance 


allow three unsuccessful logins before locking system 





put (file) 


login(ID .password) 


<- 

logoff 


display updated file structure 


I 

update file system 


update log file 


Figure 2. BUC 1 


Boundary Use Case: 

Primary Actors: 

Other Actor: 


BUC-2 Edit User Accounts 
System Administrator 
Database 


Stakeholders and Interest: 

1. The system administrator desires to edit user accounts stored in the database. 
Most user accounts will be created and edited by users as in UC-1 and UC-3. A 
system administrator will also have the ability to edit user accounts. 

Entry conditions: 

1. The system is operational and the database is accessible. 

Exit conditions: 

1. The database is updated with the new information or the information is properly 
deleted from the database. 

Flow of events: 

1. The system administrator is correctly identified and authenticated, gaining access 
to edit the database via an administration tool. 
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2 . 


The system administrator uses the administration tool to add new user account 
information. 

3. The changes are saved on the database and the database is updated. 

4. The system administrator logs off of the system, ending the update session. 

5. The system maintains a log of all events during this session. 

Exceptions: 

*. System is unavailable. System shows error message. 

la. The system administrator does not provide an authorized identification or 
password. 

1. The system shows an error message and allows for another 
attempt. 

2. Repeat this for a total of three times before system locks for 30 
minutes. 

a. System updates log of failed attempt. 

b. System allows the update capability to be restored after 30 
minutes. 

2a. The system administrator desires to update or edit an existing user 
account. 

1. The system administrator locates the desired account information. 

2. The changes are made. 

3. The database changes are saved and the database is updated. 

2b. The system administrator desires to delete an existing user account. 

1. The system administrator locates the desired user account. 

2. The account is deleted from the database. 

3. The database changes are saved and the database is updated. 
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Boundary Use Case: 

Primary Actors: 

Other Actors: 


Figure 3. BUC 2 

BUC-3 Update Awards Stored on Database 

System Administrator 

Database 


Stakeholders and Interest: 

1. The system administrator desires to add or remove an award from the database. 
The database will store photographs of all Department of Defense approved 
awards. The database will need to be initially populated with authorized awards. 
As new awards are authorized, the database will need to be updated. 

Entry conditions: 

1. The system is operational and the database is accessible. 

Exit conditions: 

E The database is updated with the new information or the information is properly 
deleted from the database. 

Flow of events: 

1. The system administrator is correctly identified and authenticated, gaining access 
to edit the database via an administration tool. 

2. The system administrator uses the administration tool to add a new photograph of 
a DOD approved award. 

3. The changes are saved on the database and the database is updated. 

4. The system administrator logs off of the system, ending the update session. 
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5. 


The system maintains a log of all events during this session. 


Exceptions: 

*. System is unavailable. System shows error message. 

la. The system administrator does not provide an authorized identification or 
password. 

1. The system shows an error message and allows for another 
attempt. 

2. Repeat this for a total of three times before system locks for 30 
minutes. 

a. System updates log of failed attempt. 

b. System allows the update capability to be restored after 30 
minutes. 

2a. The system administrator desires to delete an existing award photograph. 

1. The system administrator locates the desired photograph. 

2. The photograph is deleted from the database. 

3. The database changes are saved and the database is updated. 



Figure 4. BUC 3 
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J. USE CASES 

Use case: 


UC-1 Set Up Account 
Primary Actor : Prospective User 

Other Actor: Data Base 

Stakeholders and Interest: 

1. Prospective user wants to create a user name and password to access the site and 
set account information. 

Entry conditions: 

1. System is operational. 

2. Prospective user has access to the internet and the system is accessible. 

3. Prospective user has correctly entered the URL into a browser and the system has 

responded with the log in page. 

Exit conditions: 

1. Prospective user completes the required account information inputs and is sent a 
verification of account set up by the system. 

Flow of events: 

1. Prospective user selects the new user link from the log in page. 

2. System displays the account information page with required input fields. 

3. Prospective user fills in the account information. 

4. Prospective user submits account information. 

5. System updates internal database with new information. 

6. System sends a verification of a successful account set up. 

Exceptions: 

*. The prospective user cancels the procedure at any time. All the data are purged from 
the system. 

2a. Page is not available to be returned to the user. 

1. System displays an error message. 

2. Repeat step 1 in flow of events. 

5a. System rejects application due to inadequate information. 

1. System directs Prospective user to complete affected areas of application. 

2. Repeat step 3 in flow of events. 

5b. System rejects application due to duplication found in user name. 

1. System directs the Prospective user to use a different user name 
for this account. 

6a. System fails to send a verification message. 

1. Repeat step 1 in flow of events. 
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Use case: UC-2 Log-In 

Primary Actors: Prospective User 

Other Actor: Data Base 

Stakeholders and Interest: 

1. Prospective user wants to access the system. 

Entry conditions: 

1. UC-1 completed. 

2. System is operational. 

3. Prospective user has access to the internet and the system is accessible. 

4. Prospective user has correctly entered the URL into a browser and the system has 
responded with the log in page. 

Exit conditions: 

1. User has successfully logged in to the system. 

Flow of events: 

1. User enters user name and password in order to access the system. 

2. The system validates the entered information. 

a. In case data is invalid: Inform the customer and proceed to step (2) 

b. In case data is valid: 

1. System displays the home page. 

2. Personalized welcome message displayed on home page. 

3. System filters all information according to account information 
such as rank, gender, awards, etc. 

Exceptions: 

*a. Customer is locked out after three (3) unsuccessful attempts to log-on. 

la. User forgets user name or password. 

1. User selects the forgotten user name/password link. 

a. System sends a blank information page with inputs for: 

Last Name 
First Name 
Rank 
Gender 

E-Mail address 
User Name 
Password 

b. User must input at least four fields. 

c. System verifies these four fields. 

1. If the fields verify successfully, system e-mails user name and password to e-mail 
address. 
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2 . 


If the fields cannot be verified, the system notifies the user. 


Use case: UC-3 Update Account Information 

Primary Actors: Prospective User 

Other Actor: Data Base 

Stakeholders and Interest: 

1. Prospective user wants to update his account information that is currently stored 
in the data base. 

Entry conditions: 

1. UC-1, Set Up Account, completed. 

2. UC-2, Log-In, completed. 

Exit conditions: 

1. User has successfully updated account information. 

Flow of events: 

1. User selects the update personal information link from the home page. 

2. The system displays all current fields stored in the database. 

3. User updates one or more fields with new information. 

4. System updates the database with new information. 

5. System sends a verification of a successful account update. 

Exceptions: 

*. The prospective user cancels the procedure at any time. All the new data are purged 
from the system and old data are restored. 

4a. System rejects application due to duplication found in user name. 

1. System directs the Prospective user to use a different user name for 
this account. 

5a. System fails to send a verification message. 

1. Repeat step 1 in flow of events. 


Use case: UC-4 Choose Uniform for Own Rank 
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Primary Actors: 
Other Actor: 


Prospective User 


Stakeholders and Interest: 

1. User wants to find a uniform authorized for own rank. 


Entry conditions: 

1. UC-1, Set Up Account, completed. 

2. UC-2, Log-In, completed. 

3. System has filtered available information based on the user’s account information 
Exit conditions: 

1. System displays the desired uniform. 


Flow of events: 

1. User selects a particular type of uniform from the following list: 

Evening Dress 
Blue Dress 
Service 

Combat Utility 
Specialty 

2. System displays the sub-categories. 

3. User selects a particular uniform from the sub-categories. 

a. System displays photo of the selected uniform. 

b. System displays text from Marine Corps Order (MCO). 


Exceptions: 

*. System unable to display selected information. System shows error message, 
la. User wants to change selection to a different type of uniform. 

1. Repeat step 1 from flow of events. 

3a. User wants to change selection to a different type of uniform. 

1. User selects “new uniform type” link. 

2. Repeat step 1 from flow of events. 

3b. User wants to change selection to a different uniform within the same 
type. 


1. Repeat step 3 from flow of events. 
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Use case: UC-5 Choose Uniform From Any Rank/Gender 

Primary Actors: Prospective User 

Other Actor: 

Stakeholders and Interest: 

1. User wants to gather information and photos on uniform regulations for ranks or 
genders other than his own. 

Entry conditions: 

1. UC-1, Set Up Account, completed. 

2. UC-2, Log-In, completed. 

3. System has filtered available information based on the user’s account information 
Exit conditions: 

1. System displays uniform for any selected rank or gender. 

Flow of events: 

1. User changes the rank to the desired rank. 

2. System filters available information to selected rank. 

3. System disables personal awards feature that displays the user’s awards. 

4. User changes the gender to the desired gender. 

5. System filters available information to selected gender. 

6. User selects a particular type of uniform from the following list: 

Evening Dress 
Blue Dress 
Service 

Combat Utility 
Specialty 

7. System displays the sub-categories. 

8. User selects a particular uniform from the sub-categories. 

a. System displays photo of the selected uniform. 

b. System displays text describing the uniform in accordance with Marine Corps 
Order (MCO). 

Exceptions: 

*. System unable to display selected information. System shows error message, 
la. User desires to change to any rank at any time. 

1. Repeat step 1 from flow of events. 

4a. User desires to change gender at any time. 

1. Repeat step 4 from flow of events. 

6a. User wants to change selection to a different type of uniform. 

1. Repeat step 6 from flow of events. 

8a. User wants to change selection to a different type of uniform. 

1. User selects “new uniform type” link. 

2. Repeat step 6 from flow of events. 

8b. User wants to change selection to a different uniform within the same type. 

Repeat step 8 from flow of events: 
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Use case: UC-6 Display Measurements for Uniform Items 

Primary Actors: Prospective User 

Other Actor: 


Stakeholders and Interest: 

1. User desires measurement specifications for any part of the uniform such as 
trouser length, belt length, blouse arm length etc. 

Entry conditions: 

1. UC-4, Choose Uniform for Own Rank or UC-5, Choose Uniform From Any 

Rank/Gender completed. 

Exit conditions: 

1. System displays desired measurements on photo and also displays the 
corresponding text from the MCO. 

Flow of events: 

1. User mouses over hotspots that dissect the photo of the desired uniform. 

2. System magnifies the area as it is moused over. 

3. User selects desired area. 

4. System displays a short description on the photo. 

5. System displays the detailed verbiage associated with the selected area in 
accordance with MCO. 

Exceptions: 

*. System unable to display selected information. System shows error message. 

3a. User desires to select a different area. 

1. Repeat step 3. 
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Use case: 
Primary Actors: 


UC-7 Display Grooming Standards 
Prospective User 


Other Actor: 


Stakeholders and Interest: 

1. User desires the USMC grooming standards. The grooming standards can be 
accessed by a link from the main menu or from any photo of a desired uniform. 

Entry conditions: 

1. UC-2, Log-In, completed. 

Exit conditions: 

1. System displays desired grooming standards on photo and also displays the 
corresponding text from the MCO. 


Flow of events: 

1. User desires information regarding grooming standards. 

a. User selects grooming standards link from the main menu. 

a. System displays a large view of the head area with hotspots 
that dissect the area further. 

b. User mouses over hotspots of the head area on the 
displayed photo as in UC-6. 

1. System magnifies the area as it is moused over. 

2. User selects desired area. 

3. System displays a large view of the head area with 
hotspots that dissect the area further. 

2. User selects the specific area desired. 

3. System displays a short description on the photo. 

4. System displays the detailed verbiage associated with the selected area in 
accordance with MCO. 


Exceptions: 

*. System unable to display selected information. System shows error message, 
la. User selects a different link from the main menu. 

2a. User desires a different area. 

1. Repeat step 2 in flow of events. 
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Use case: UC-8 Display Awards Precedence 

Primary Actors: Prospective User 

Other Actor: Database 

Stakeholders and Interest: 

1. User desires to see the display in order of precedence of own awards or entered 
awards. The awards can be accessed from the main menu or from linking to the 
hotspot found on the main photo as in UC-6, Display Measurements for Uniform 
Items. 

Entry conditions: 

1. UC-1, Set Up Account, completed. 

2. UC-2, Log-In, completed. 

3. If the awards are to be accessed from the displayed photo vice the main menu, 
UC-6, Display Measurements for Uniform Items, must be completed. 

Exit conditions: 

1. System displays the photos of the desired awards in the correct order of 
precedence in accordance with the MCO. 

Flow of events: 

1. User desires to view awards precedence or measurements of awards and insignias 
as stored under his user name. 

a. User selects awards from the main menu or user selects the awards hotspot 

found on the displayed photo as in UC-6, Display Measurements 
for Uniform Items. 

b. System accesses the data base and retrieves the previously stored 
information as created in UC-1, Set Up Account. 

2. User desires to view awards precedence or measurements of any awards. 

a. User selects the input awards link. 

b. User inputs the desired awards and insignias. 

3. The system retrieves all images to corresponding awards and arranges them in 
order of precedence in accordance with MCO. 

4. The system displays the images along with the correct measurements of awards 
and insignias in accordance with MCO. 

Exceptions: 

*. System unable to display selected information. System shows error message, 
la. User desires to update existing awards data base. 

1. User selects update awards link. 
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2. User changes account information as in UC-3, Update Account 
Information. 

3. Repeat step 1 in flow if events. 


K. SEQUENCE DIAGRAMS 

Set Up Account: 



Figure 6. Set Up Account 


Log-In: 



Figure 7. Log-In 
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Update Account Information: 


Prospective User 


System 



updateAccount 



<- 

display Account Information 



update Account Information 



- 

verify New Information 



concur with New Information 



<- 

verify updates 







get Account Information 


update Account Information 


Figure 8. Update Account Information 


Data Base 


> 


77 

































Choose Uniform for Own Rank: 


Prospective User 


System 


select uniformType 

<- 

display uniform sub-categories 


All uniforms will fall into a hierarchy. 

For example, service uniforms will 
contain the sub-categories of Service A, 
Service B, and Service C. 


select uniform 


-te. 


display photo 


display text 


Figure 9. Choose Uniform for Own Rank 
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Choose Uniform From Any Rank/Gender: 



Figure 10. Choose Uniform From Any Rank/Gender 
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Display Measurements for Uniform Items: 



Figure 11. Display Measurements for Uniform Items 
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Display Grooming Standards: 


Prospective User 


System 



selectGroomingStandards 




display view of head with hotspots 




The view of the head will be of the same gender selected for uniform type! 



mouseOverHotSpots 




magnify selected area 



selectHotSpot 




display photo 




display text 




The text displayed will be grooming standards in accordance with MCOl 






Figure 12. Display Grooming Standards 
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Display Awards 
Precedence: 


Prosnective User 


System 


Data Base 


selectAwards 


This can be done from the main menu or from the hotspot 
found on the displayed photo as in UC-6, Display 
Measurements for Uniform Items. 


display awards 
display text 


«=- 


getAwards 


Awards are stored in user account as 
created in UC-1, Set Up Account. 


sendAwards 


irrangeAwards 

■4 


Awards are arrange by precedence in 
accordance with MOO 


Figure 13. Display Awards Precedence 
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FLOW CHARTS 
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Account 

Setup 


Account 
Last Name 
First Name 
Gender 
Rank 
Awards 
User Name 
Password 
MOS 
E-mail 


Stored 


Database 
Accounts 
Award Pictures 


Create 

Account? 


Enter as 
Guest? 


Show 

Guest 

Homepage 


r \ 

Start Page 

\- J 


Account 


-yea 


No 

(After 3 tries: 
block IP) 


Verify with database 


Remember 
Password\ 
User Name? 


-yes ► 


G etPassword / 
Username 

Last Name 

First Name 

Gender 

Rank 

Awards 

User Name 

Password 

MOS 

E-mail 


Verify 


yes 


E-mail 

Password 


Verify with database 

Figure 14. Flow Chart 1 


Enter iD/PW 


Verify 


Show 

User 

Homepage 
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yes 



Figure 15. Flow Chart 2 
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M. HOME PAGE INFORMATION 
1. Home Page Selections 


Uniforms 

Grooming Standards 
Awards 

Civilian Clothes 
PT Gear 
Musical Units 
Organizational Clothing 
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2 . 


Home Page Flow Charts 



Figure 16. Home Page Flow Chart 


Show photograph as 
indicated in figure 1 
below. 
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Footwear 


Rank 


Insignia 

and 

Buttons 


Blouse/ 

Jacket 


Belt 


Grooming 

Standards 


Medals/ 

Ribbons 


Overlap 
Measurements 


Sleeve 

Length 


Trousers 


Trouser 

Length 


Optional Items 

Gloves 

Sword 

Overcoat 

Sam Brown Belt 

Etc. 


Cover 


Figure 17. Typical Sections for a Photograph 


87 

























88 




































Figure 19. Organizational Menu 
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II. SOFTWARE DESIGN SPECIFICATIONS (SDS) 


A. REVISION SHEET 


Revision Number 

Date 

Brief Description of Changes 

001 

26 Feb 2006 

Version 1 completed and submitted to Prof. Shing 
























































B. INTRODUCTION 

1. Purpose 

The purpose of the Software Design Specification (SDS) is to describe the 
functionality of the Web Based Uniform Manual. The SDS will be presented to the 
customer for review, comment, and validation of the design. This document describes 
the subsystems and modules that form the Graphical User Interface, server requirements, 
and Database requirements. The SDS provides highly detailed technical data, system 
information, and other relevant information on the Web Based Uniform Manual. This 
document includes an architecture diagram, a design class diagram, interaction diagrams, 
state diagrams, and a glossary. 

2. Scope and Audience 
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The web based manual described in this document will be in strict accordance 
with MCO P1020.34G. This system will be relied on by Marines world wide as an 
accurate source of standards that ensure their compliance with the MCO. The new 
design will be IAW the principles of HCI and will support quick links and menu driven 
systems that will allow all relevant information to be displayed or hidden as the user 
requires. The new system will address all aspects currently outlined in the regulations, 
such as proper wearing of the uniform, grooming standards, ribbon and medal 
precedence, civilian attire, PT gear, and optional items for male and female officers and 
enlisted U. S. Marines. This system could be used by all US civilians and military 
service members to whom the current manual is now relevant. 

3. Goal Statement 

The overall goal of the project will be to create an easy to use GUI based uniform 
regulation guide. This system will be web based and will be designed to accommodate 
further maintenance and reuse. 

4. Implementation & Special Features 

The guide will be implemented using primarily visual aides and follow the 
practices of good Macro/Micro HCI Design. The aim will be to provide the needed 
information to the user in an easy to use GUI interface that requires minimal “mouse 
clicks” to retrieve the desired information. The guide will also provide the user with 
alternative text from the Marine Corps Order P1020.34G dealing with the specific 
uniform in question. The end result will be an easy to use research tool that may be 
utilized by members of the United States Marine Corps to ensure that their uniform is 
within regulations. 

5. System Use 

The use of the system will support quick links and menu driven systems that will 
allow all relevant information to be displayed or hidden as the user requires. The new 
system will address all aspects currently outlined in the regulations and described in the 
Requirements Analysis Document referenced. This system will be used by all US 
civilians and military service members to whom the current manual is now relevant. 

6. REFERENCES 
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• Bruegge, Bernd. Object-Oriented Software Engineering. Pearson Prentice 
Hall, Inc. 2004 

• Larman, Craig. Applying UML and Patterns: an introduction to object 
oriented analysis and design and iterative development. Pearson 
Education Inc. 2005. 

• Braude, Eric. Software Design: From Programming to Architecture. 
Wiley, Inc. 2004. 

• M. Villar, C. Krause. Web Based Uniform Regulations Manual 

Requirements Analysis Document. Naval Postgraduate School. Monterey, 
CA. January 2006. 

C. HCI DESIGN AND JUDGMENT CATEGORIES 

1. Simplicity 

Simplicity provides the means by which the web page aims to keep the basic 
utility of the interface easy to use, and offer facilities which are of a clear value to the 
military member. The interface should be intuitive and there should be no question as to 
how to use this manual. 

2. Consistency 

The user should feel that he or she is in control and that the system is responding 
to his or her actions accordingly. Users should have control over the amount of 
information they receive at different points of the interaction. During the interaction, the 
web page should have a common look and presentation that is presentable and 
professional. As shown in Figure 16, this manual will be broken up into four main 
categories; male officer, male enlisted, female officer, female enlisted. During 
exploration of this manual, each category will be easily identified. This will allow for 
ease of presence within this site. 
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Figure 20. Four Main Categories 


3. Control 

Control actions initiated by the user should receive the appropriate responses. 
Error and control messages should generate the same responses throughout this site. 

4. Shortcuts and Customization 

The web page should present mechanisms for users to customize settings to speed 
frequency of use by users. 

5. Screen layout 

The screen layout should give an appearance of clarity with the proper use of 
white space to separate items. Items should be presented in a balanced fashion, and not 
distort during screen resolution change. Additionally, control maneuvers should be 
reachable without scrolling extensively. 

6. Feedback 

Appropriate feedback before, during, and after interaction is essential to proper 
HCI. Prompts and directions should be provided to the user at all times. The user should 
never be left in a state of question. 

7. Error Handling 

There shall be no means of deleting or changing information. This action will 
allow the user freedom of experimentation without degradation of the information 
presented on this site. This will ensure error handling is at a minimum in regards to 
development of this site. 
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8. Efficiency 

All accessible elements of the web page are generated in a timely manner. The 
information provided within this site will be in conjunction with the latest regulation 
regarding the specific uniform in question. In an effort to speed efficiency, a “SEARCH” 
feature should also be implemented. The added feature will allow expert users extended 
usability of this manual. 

9. Help Facilities 

The web page will provide a mechanism to report problems or errors. Additional 
help facilities regarding military uniform regulations will also be provided. 

10. Navigation 

Navigation within the web presence should be easily achieved with minimal 
“clicks” or drop down menus to achieve a desired result. 

11. Objects 

Each major category will have similar index pages and file structures. The 
objects that will be created from the index page as the user completes a search for desired 
information are shown in Figure 17. Generic layouts for other pages are shown in 
Figures 18 and 19. These are not objects as normally recognized in object oriented 
programming, but we refer to them as objects for explanatory purposes. Since this entire 
system is web based, objects are not truly created but rather each selection calls a desired 
page within the web server. 
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Navigation Bar 

Home Uniforms Grooming Awards Rank Insignia Civilian Clothes PT Gear Organizational Musical Units 


Member Info 

Male/Female 

Rank 

Main Photo Area 

Contact Info 
Help 

Manual 

Detailed Text from Marine Corps Order P1020.34G MCO 

Links 


Figure 21. Index Page Layout 


Navigation Bar 

Home Evening Blue Dress Blue/White Dress Service Utility 

Links 

Main Photo Area 

Detailed Text from Marine Corps Order P1020.34G MCO 


Figure 22. Typical Uniform Page Layout 
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Navigation Bar 

Home Evening Blue Dress Blue/White Dress Service Utility 


Optional 

Items 

Main Photo Area 

Detailed 

Sections 

Detailed Text from Marine Corps Order P1020.34G MCO 


Figure 23. Typical Uniform Type Page Layout 



D. MAINTAINABILITY 

This system must be designed in order to allow for easy maintenance. The 
designers of this system will not be responsible for any future maintenance of this 
system. It is our intention to build this site and turn all files over to Headquarters Marine 
Corps for implementation. Our design goal is to allow this site to be usable for many 
years to come within the Marie Corps. This can only be achieved if the site is easily 
maintainable and files can be edited or deleted as the MCO changes. In order to achieve 
the desired maintainability, the design must adhere to the following: 

1. Reliability 

The reliability of this system will be dependent on the stability of the code and the 
capacity for system upgrades. The design of this system will be done with the goal of 
system reliability in mind. 

2. Efficiency 

This system must be designed to maximize the efficiency of the code. This will 
be done by inhibiting overloading and preventing unnecessary parts of the code. All 
written code will be thoroughly scrubbed for gratuitous code or files. 
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3. Understandability 

This will be a key aspect to maintaining this site. The documentation provided 
here as well as the structure of the files will help future maintainers to understand the site 
and assist in implementing any changes. It is unknown as to the technical expertise and 
experience of the future maintainer of this site so full documentation is critical. 

4. Measurability 

Software metrics can be used to estimate the project budget and schedule, 
evaluate individual productivity and quality, evaluate project productivity and quality, 
and evaluate the system quality. 

E. REUSE 

The design specifications for this system call for the design of a web based 
uniform manual for the United States Marine Corps. However, the same need can be 
paralleled to any service within the Department of Defense or any international military 
organization. This system will be designed with the concept of reuse in mind. The 
system developed here can be easily transferred into any other service branch. This will 
be done with a file structure that is generic enough to allow for the input of any uniform 
type and a system structure that can support any similar specification. 

F. SECURITY 

The information on this site needs to be in complete compliance with Marine 
Corps Order P1020.34G. Any deviations from this standard render this site useless. The 
threat of hackers is always present when dealing with the web based systems. If any user 
can break through and change any of the information on our website, it will sacrifice the 
integrity of the information posted. Once the information is found to be inaccurate, it 
will render our system unreliable and discourage its use. 

G. SYSTEM ARCHITECTURE 

The Web Based Uniform Regulations Manual is organized into a three-tier closed 
architecture composed of a presentation layer, application logic layer (domain), and 
storage/network layer (services). The purpose of this organization is to promote reuse, 
support distributed processing, and allow parallel team development. Also, by building 
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each layer only in terms of each immediate lower layer, this design will reduce 
dependencies between each layer enabling the system to be combined with other 
hardware/software platforms with minimal rewriting of single layers. 

The System Architecture decomposes the Web Based Uniform Regulations 
Manual system into subsystems by vertical layers and horizontal partitions. The 
presentation, domain, and service top layers are represented by the common graphical 
user interface (GUI), CTF Infrastructure, and Computer Website services subsystems 
respectively. Figure 20 illustrates the organization of subsystem layers and partitions 
within the Web Based Uniform Regulations Manual System Architecture. 
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Presentation Layer 



Figure 24. System Architecture Diagram 


H. PRESENTATION LAYER 

A web browser will function as the client interface. Its sole purpose is the display 
of the Web server generated HTML pages. To create a platform independent experience 
the page layout will be controlled by Cascading Style Sheets. These style sheets, once 
cached by the browser, will also account for faster webpage loading. All content creation 
will be done by server side PHP scripting, again contributing to a browser independent 
display without the need for client side browser plugins (like Java script), thus speeding 
up the page load time and avoiding safety critical scripting on the client computer. This 
will also allow handheld devices, which are not always equipped with scripting capable 
browser, to load and display the interface pages. 
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Figure 25. Context Diagram 

I. APPLICATION LAYER 

The middle tier is divided in two units with different functions. An intermediate 
layer (web server) implemented in a scripting language (PHP). This layer receives 
requests from the Internet clients and generates html using the services provided by the 
storage/infrastructure layer. This additional layer provides isolation between the 
application layout and the application logic. 

This system will be designed to reside on an Apache Web Server. The Apache 
Web Server has several advantages. It is extremely powerful, modular, flexible, highly 
configurable, and extensible. It is freely available through open source which means that 
its source code is examined constantly by numerous users. This constant examination by 
outsiders, makes it substantially more reliable than any commercial software product that 
can only rely on the scrutiny of a closed list of employees. Apache currently runs on 
approx. 68-70% of all web servers worldwide making it the #1 choice of web servers 
since 1996. This makes it the most secure web server worldwide. 

J. STORAGE/INFRASTRUCTURE LAYER 

The basic design philosophy that we will follow is to create four complete and 
separate sites that can actually completely stand alone and have a common link from the 
login page as shown in Figure 22. 
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Figure 26. Site Layout 


This type of architecture will allow us to extensively test while developing the 
site. We can first create the Male Officer “site” in its entirety and test this module. Then 
we can create the login page and develop its functionality. Once the login page is linked 
to the Male Officer “site”, we can exhaustively test this smaller system and develop it 
completely. Then it would simply be a duplication of the Male Officer “site” in order to 
create the Female Officer “site”, the Male Enlisted “site”, and the Female Enlisted “site” 
(allowing for the subtle nuances of each subcategory). The final step in architecture 
design will be to link all four subcategories to each index page. For example, if a user is 
currently in the Male Officer “site” and he desires to look at female enlisted uniforms, he 
can quickly access the index page of the Female Enlisted “site” and now navigate through 
that “site”. 

1. File Naming 

All four subcategories will share the same file names as shown in figure 23. This 
will allow for the quick creation of the remaining subcategories after the first one is 
created. This type of file naming pattern lends is attainable since all ranks and genders 
within the USMC must follow the same manual. Also all ranks and genders within the 
USMC have the same uniform names but the style of the uniform varies between ranks 
and gender. A clear and concise file structure is imperative for construction of this site 


101 



















and to ensure maintainability. All files need to be arranged in a manner that is easy to 
follow and is unambiguous since this system will not be maintained by the original 
design team. 

2. File Layout 

All files will be placed in one of four substructures that are referenced from a 
main index page. As mentioned earlier in this document, the files will be broken up into 
four main categories; male officer, male enlisted, female officer, female enlisted. Figure 
23 shows the file structure for male officers. This structure will be repeated for all other 
categories. 
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a Q Awards 

o My_Awards 
O New Folder 
id) Civilian_Clothes 
id) Grooming_Standards 
a Musical_Units 

o D_and_B_hjll_dress_female 
Q Full_Dress_Asst_Dir 
Q Full_Dress_Ceremonial 
id) Full_Dress_Concert 
O Full_Dress_Director 
o Full_Dress_Drum_Maj 
id) Full_Dress_Summer 
id) New Folder 
id) Special_Full_Dress_Female 
id) Special_Full_Dress_Male 


a id) Organizational 
id) BRASSARDS 
Id) BREASTCORDS 
id) CAMPAIGN_HAT 
id) FIELD_COAT 
Id) FLIGHT_CLOTHING 
id) FOOD_SERVICE_CLOTHING 
Id) HEADGEAR_SPECIAL 
id) HONOR_GUARD_EQUIPMENT 
Id) MARINE_SECURITY_GUARDS 
Id) MILITARY_POLICE_EQUIPMENT 
id) MOURNING_BAND 
Id) PHYSICAL_TRAINING_CLOTHING 
id) SAM_BROWNE_BELT 
id) SELECTED_ENLISTED 
id) SERVICE_BELT 
Id) SHORE_PARTY_DESIGNATION 
Id) SWORD_AND_SCABBARD_NCO 
id) 5W0RD_M0URNING_KN0T 
Id) TROUSERS_SKIRT5LACK5_WHITE 
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ICj) PT_Gear 
IrTl Rank_Insignia 
C Shared_Photos 
B & Uniforms 
B |£) Blue_Dress 

Q Blue_Dress_A 
tj) Blue_Dress_B 
Infi Blue_Dress_C 
IrA Blue_Dress_D 
|^| Shared_Photos 
B C Blue_White_Dress 

o Blue_White_Dress_A 
o Blue_White_Dress_B 
O Shared_Photos 
B |£| Evening_Dress 

Cl Detailed_Sections 
C Evening_Dress_A 
Q Evening_Dress_B 
IrTi Shared_Photos 
Q Optional_Items 
B S Service 

S) Service_A 
C Service_B 
C Service_C 
|^| Shared_Photos 
Q Shared_Photos 
B £) Utility 

Dessert 
Shared_Photos 
c Woodland 
Shared_Photos 


Figure 27. File Structure 

3. Database 

The Relational Database MySQL provides the persistent storage for user specific 
data. It will communicate with the presentation layer via the PHP scripting language. 

4. Security 

Apache provides security-related configuration directives enabling administrators 
to tighten the security: 
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• User / Group: Defines user/group Apache should run as 

• LimitRequestBody: Restrict total size of HTTP request body sent from a 
client 

• LimitRequestFields: Limit number of HTTP request header fields that will 
be accepted from the client 

• LimitRequestFieldSize: Limit size of the HTTP request header allowed 
from the client 

• LimitRequestLine: Limits overall size of the HTTP request line that will 
be accepted 

• Listen: Defines the IP addresses and ports the server listens on 

• ServerTokens: Server HTTP response header 

• ServerSignature: Content of footer available on server-generated 
documents 

• SSLEngine: Toggle usage of SSL/TLS protocol engine 

• UserDir: Indicates the location of user-specific directories 

K. CLASS MODEL 

Figure 24 of this document shows the system’s SCRS Class Diagram. It illustrates 
the basic context in which the whole SCRS system operates. 
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Login Page 


verifyUser_PasswordO 

getMaleOfficerlndexO 

getMaleEnlistedlndexO 

getFemaleOfficerlndexO 

getFemaleEnlistedlndexO 

createAccountO 

forgotUser_PasswordQ 


Rank and Gender 


getUniformsQ 

getAwardsO 

getGroomingO 

getCivilianQ 

getPT_GearO 

getMusicalO 

getOrganizationalO 

getRanklnsigniaO 

getHelpO 

getManualO 

getContactO 

getUnkO 

getMaleEnlistedlndexO 

getFemaleOfficerlndexO 

getFemaleOfficerlndexO 

getFemaleEnlistedlndexO 


Account 


• lastName: string 

• firstName: string 

• gender: string 

• rank: string 

• userName: string 

• password: string 


getLastNameO 

setLastNameO 

getFirstNameO 

setFirstNameO 

getGenderO 

setGenderO 

getRankO 

setRankQ 

getUserNameO 

setUserNameO 

getPasswordO 

setPasswordO 



Figure 28. Class Diagram 
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Unifoims 


getEveningAO 

getEveningBO 

getBlueDressAO 

getBlueDressBO 

getBlueDressCO 

getBlueDressDO 

getBlueWhiteDressAO 

getBlueWhiteDressBO 

getServiceAO 

getServiceBO 

getServiceCQ 

getWoodlandO 

getDessertQ 



Evening A 
Evening B 


Bine Diess A 




^/ 

Unifoim Styles 


getOptionalltemsO 

getDetailsQ 


Bine Diess B 


Bine Dress C 




Service C 

Service B 



Seivice A 


3ltie Diess D 


Blue White Dress B 

Bine White Diess A 



Figure 29. Class Diagram 


L. LOGIN PAGE 

1. verifyUser_Password() 

A password is provided by the user and passed by the web browser to the system. 

2. getMaleOfficerIndex() 

Used to get the index page of the Male Officer Subcategory. 

3. getMaleEnlistedIndex() 

Used to get the index page of the Male Enlisted Subcategory. 

4. getFemaleOfficerIndex() 

Used to get the index page of the Female Officer Subcategory. 

5. getF emaleEnlistedIndex() 

Used to get the index page of the Female Enlisted Subcategory. 

6. createAccountO 

The user desires to create a new account which is passed to the system by the web 
browser. 

7. forgotUser_Password() 
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The user needs a reminder of his password which is passed to the system by the 
web browser. 

M. ACCOUNT 

1. lastNamerString 

Used for the last name of the user account. 

2. firstName: String 

Used for the first name of the user account. 

3. gender: String 

Used for the gender of the user account. 

4. rank: String 

Used for the rank of the user account. 

5. username: String 

Used for the user name of the user account. 

6. password: String 

Used for the password of the user account. 

7. getUastName() 

Once the account is set up, this method will be used to retrieve the user’s last 
name from the database. 

8. setUastNameO 

This method will be used to set up an account in the database with the user’s last 

name. 

9. getFirstNameO 

Once the account is set up, this method will be used to retrieve the user’s first 
name from the database. 

10. setFirstNameO 

This method will be used to set up an account in the database with the user’s first 

name. 


11. getGender() 

Once the account is set up, this method will be used to retrieve the user’s gender 
from the database. 

12. setGender() 

This method will be used to set up an account in the database with the user’s 

gender. 


13. getRankO 

Once the account is set up, this method will be used to retrieve the user’s rank 
from the database. 
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14. setRank() 

This method will be used to set up an account in the database with the user’s rank. 

15. getUserName() 

Once the account is set up, this method will be used to retrieve the user’s user 
name from the database. 

16. setUserName() 

This method will be used to set up an account in the database with the user’s user 

name. 

17. getPasswordO 

Once the account is set up, this method will be used to retrieve the password from 
the database. 


18. setPasswordO 

This method will be used to set up an account in the database with the user’s 
password. 

N. RANK AND GENDER 

1. getUniformsO 

This method will be used to get the Uniforms HTML page. 

2. getAwards() 

This method will be used to get the Awards HTML page. 

3. getGroomingO 

This method will be used to get the Grooming Standards HTML page. 

4. getCivilian() 

This method will be used to get the Civilian ClothesHTML page. 

5. getPT_Gear() 

This method will be used to get the PT Gear HTML page. 

6. getMusical() 

This method will be used to get the Musical Organizations HTML page. 

7. getOrganizational() 

This method will be used to get the Organizational HTML page. 

8. getRankInsignia() 
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This method will be used to get the Rank Insignia HTML page. 


9. getHelpO 

This will be a function that allows the user to request guidance on any object or 
function that may be unclear. 

10. getManual() 

This will list the current versions of the uniform regulations manuals used for this 
web site. 

11. getContactO 

This will display the contact information of the web designer and manager. This 
will also contain contact information for Marine Corps’ uniform regulations department 
which can provide answers to any specific uniform item questions. 

12. getLink() 

This is a generic name for this method used only for this document. The actual 
site will contain several links that will be later determined. Each link will require a 
method that will allow the web browser to display the desired link. 

13. getMaleEnlistedIndex() 

This method will be used to get the index page for the Male Enlisted subcategory. 
This will allow the user to navigate to any desired rank and gender. 

14. getFemaleOfflcerlndexO 

This method will be used to get the index page for the Female Officer 
subcategory. This will allow the user to navigate to any desired rank and gender. 

15. getMaleOfficerIndex() 

This method will be used to get the index page for the Male Officer subcategory. 
This will allow the user to navigate to any desired rank and gender. 

16. getF emaleEnlistedIndex() 

This method will be used to get the index page for the Female Enlisted 
subcategory. This will allow the user to navigate to any desired rank and gender. 

O. UNIFORMS 

Each rank and gender has the same uniform names for each uniform. 
However, the uniforms vary for each rank and gender while the names are shared. The 
following methods will get the correct uniform as filtered by the rank and gender. 

1. getEveningA() 

This method will get the Evening A HTML page. 
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2. getEveningB() 

This method will get the Evening B HTML page. 

3. getBlueDressA() 

This method will get the Blue Dress A HTML page. 

4. getBlueDressB() 

This method will get the Blue Dress B HTML page. 

5. getBlueDressC() 

This method will get the Blue Dress C HTML page. 

6. getBlueDressD() 

This method will get the Blue Dress D HTML page. 

7. getBlueWhiteDressA() 

This method will get the Blue White Dress A HTML page. 

8. getBlueWhiteDressB() 

This method will get the Blue White Dress B HTML page. 

9. getServiceA() 

This method will get the Service A HTML page. 

10. getServiceB() 

This method will get the Service B HTML page. 

11. getServiceCO 

This method will get the Service C HTML page. 

12. getWoodlandO 

This method will get the Woodland HTML page. 

13. getDessert() 

This method will get the Dessert HTML page. 

P. UNIFORM STYLES 

1. getOptionalltemsO 
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Each rank and gender has different optional items for each uniform. This method 
will be used to get the optional items for the selected uniform as filtered by the selected 
rank and gender. 

2. getDetails() 

Each uniform has its own set of detailed measurements and specifications that are 
also dependent on rank and gender. This method will be used to get the details for the 
selected uniform as filtered by the selected rank and gender. 

Q. TYPICAL USE 

• The user desires the measurements of a particular uniform. 

• User will locate web presence at the assigned URL. 

• User will log in with user name and password. 

• The system will filter based on the stored rank and gender for the user and 
send the appropriate subcategory index page to the web browser. 

• The user will select “Uniforms” from the navigation bar. 

• The system will send the Uniforms HTML page to the user’s web browser. 

• As the user is scrolling the list of uniforms, a photograph of the uniform will 
be displayed in the “Uniform Picture” section. 

• Once the appropriate uniform has been found, the user can search the detailed 
section of the uniform for specific regulations or the user can view the 
optional items for the selected uniform. 

• The exact text from the MCO will be displayed in the text area for each 
selected item. 

• The user will end their session. 

R. DETAILED DESIGN LANGUAGE 

1. HTML Language Choice 

Due to the nature of the web page, the language of choice for this project 
will be Hyper-Text Mark up Language (HTML). The majority of the pages will be 
constructed using this language with additional Java Script being used as necessary. 

2. HTML Language Definition 

The following table identifies the basic language constructs that will be used to 
develop this site. 
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A HREF 

Identifies a hyperlink 

<A HREF='’NAME'’ 
</A> 

APPLET 

Inserts a call to a 

JAVA applet into an 
HTML document 

<APPLET> 

</APPLET> 

BODY 

Outlines body text 

<BODY> 

</BODY> 

BR 

Line break 

<BR> </BR> 

CENTER 

Centers text between 
container 

<CENTER> 

</CENTER> 

DIV 

Identifies division 
containers 

<DIV> </DIV> 

FONT 

Sets font size 

<FONT> <FONT> 

HI 

Identifies a level one 
heading, and may 
contain successive 
layers 

<H1> </Hl> 

HTML 

Begins the HTML 

<HTML> 

</HTML> 

IMG SRC= 

Identifies inclusion of 
an image 

<IMG SRC=”NAME”> 

LI 

Identifies a list item 

<LI> NO 

ENDING 

TITLE 

Identifies the title of 
the HTML document 

<TITLE> 

</TITLE> 

SCRIPT 

Inline script 

<SCRIPT> 

</SCRIPT> 

TABLE 

Creates a table 

<TABLE> 

</TABLE> 

TBODY 

Defines the tables body 
when headers and 
footers are defined 

<TBODY> 

</TBODY> 

TD 

Provides a table cell 

<TD> </TD> 

TH 

Provides table 
headings 

<TH> </TH> 

TR 

Provides a table row 

<TR> </TR> 


Comments 

<!— HI THERE -> 

SCRIPT 

Inline script 

<SCRIPT> 

</SCRIPT> 


Table 1. HTML Tags 
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S. DESIGN AND DEFICIENCY MAINTENANCE 

1. Deficiency Prioritization 

Each deficiency that is found will be prioritized and worked on according to time 
and risk factors. The formula used for this assessment follows: 

Estimated Deficiency Requirement (DR) Time / Total DR Times = DR frequency 

ratio 

(DR frequency ratio * Priority) *100 = Risk Factor. 

During the initial stages of the project, we will outline a cut off Risk Factor of 
50%. This value will be the determining threshold by which deficiencies will be 
corrected and implemented into the project. The remaining DR’s from the cycle will be 
implemented as time permits. 

2. Deficiency Risk Analysis 

The following table will be used as a tracking mechanism to ensure DR’s are not 
overlooked and are corrected in a timely manner. This chart will be used to prioritize 
deficiencies noted in the product, apply the above risk formula, and correct them based 
on risk value. 


DR# 

DESCRIPTION 

EST 

HRS 

RISK FREQ 

PRIORITY 

RISK 











































Totals 







Table 2. Risk Matrix 

T. EARLY USABILITY ANALYSIS 

1. Description of analysis subjects 

We have developed paper sketches of the web interface to be used in this early 
usability analysis. Two subjects were chosen for the initial usability test of the web 
interface. The first subject was a civilian NPS student with no military experience. The 
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second subject was a Marine 1st Lieutenant with five years of military experience. 
Subjects of widely differing backgrounds and military experience were selected in order 
to get a true feel for the usability of the product. There was no user’s manual provided, 
however the website gives users guided instruction on available options. The same 
prototype sketch was given to each subject during separate analysis sessions. 

2. Rating criteria for analysis 

The HCI design and judgment criteria as set forth in Section C of this document 
was provided and explained to the test subjects. The subjects were asked to rate the 
interface on a scale of 1-10 (1 being poor, and 10 being excellent). The subjects were 

also given the option to rate an area N/A if the subject felt the criteria could not be judged 

from the initial usability test. Finally, the subjects were asked for any feedback outside 
the focus of the given criteria. 

3. Analysis 


CRITERIA 

RATING 

Ease of use 

9 

Quality of information provided 

10 

Accuracy of information provided 

N/A 

Interface efficiency(i.e. minimal number of operations 
required to get desired info) 

10 

Error free design 

9 

Ease of navigation 

8 

System help function adequate 

N/A 

Capability to satisfy expert users 

10 


Table 3. Subject 1 

Subject #1 was the civilian NPS student, and he thought the interface was 
extremely well done. He found the page was well laid out with nice drop down menus 
and links. The subject’s inexperience with the military made the initial navigation 
difficult, but he felt that the interface was designed with the novice in mind. This attribute 
allowed him to catch on quickly. Additionally, he mentioned that the presentation of the 
radio buttons used on the second to last interface sketch was unclear, specifically on how 
many buttons could be selected. Overall, he gave it an excellent rating. 
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CRITERIA 

RATING 

Ease of use 

9 

Quality of information provided 

10 

Accuracy of information provided 

10 

Interface efficiency(i.e. minimal number of operations 
required to get desired info) 

9 

Error free design 

9 

Ease of navigation 

8 

System help function adequate 

N/A 

Capability to satisfy expert users 

9 


Table 4. Subject 2 

Subject #2 was the Marine 1st Lieutenant, and he thought the interface was 
extremely well done as well. He too did not like the radio buttons used on the second to 
last sketch; he would prefer drop down menus. Additionally, he would prefer a larger 
representation of the uniform insignia presented on the last sketch. He commented that an 
interface like this is long overdue. Overall, ha gave an excellent rating. 

4. Conclusion 

The initial usability test was a very positive analysis with great feedback provided 
by both subjects. Some of the difficulties encountered during testing were a result of 
utilizing a paper interface rather than a real GUI interface where navigation would 
potentially be more intuitive and obvious as images and hotspots appear. All 
recommendations will be considered and should be easy to fix and implement. 


116 




U. TABLE OF UNIFORMS 


Evening Dress A 


Evening Dress B 
Blue Dress A 


Blue Dress B 


Blue Dress C 


Blue Dress D 


Male Non NCO 
N/A 


N/A 

Just like NCO 
except 

without blood 
stripe 



Just like NCO 
except 

without blood 
stripe 


Just like 


Male NCO 
N/A 


N/A 



Just like 
Non NCO 
except 
with blood 
Stripe 


Male SNCO 



Same as A 



Just like 
Non NCO 
except 
with blood 
stripe 




Just like 


Just like 


117 


















Blue-White Dress 
A 


Blue-White Dress 


Male Non NCO 
Blue Dress C 
except with 
short sleeve 
and no blood 
stripe 



Male NCO 
Blue Dress C 
except with 
short sleeve 



Male SNCO 
Blue Dress C 
except with 
short sleeve 



_B_ 

Service A 

Note: garrison 
cover can be worn 
instead of 
combination cover 
with all service 
uniforms 


Service B 
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Woodland Utility 


Dessert Utility 


(Officer Shown) 


(Officer Shown) 


(Officer Shown) 








Table 5. Male Enlisted Uniforms 
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Evening Dress A 


Evening Dress B 

Note: only 
difference 
between A and B 
is whit waistcoat 
is worn with A 
and scarlet 
waistcoat or 
cummerbund is 
worn with B 
Blue Dress A 


Male WO/Co Grade 
_ Officer _ 

Same as Field 
Grade except 
different cover and 
sleeve device 


Male Field Grade 
Officer 



Male Flag 
_ Officer _ 

Same as Field 
Grade except 
different cover and 
sleeve device 



Same as Flag 
Officer except 
different cover and 
sleeve device 



Same as Field 
Grade except 
different cover 



Same as Field 
Grade except 
different cover 
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Blue Dress B 


Blue Dress C 


Male WO/Co Grade 
Officer 




Male Field Grade 
_ Officer _ 

Same as Company 
Grade except 
different cover 


Same as Company 
Grade except 
different cover 


Blue Dress D 


Blue-White Dress 
A 



Same as Company 
Grade except 
different cover 


Same as Company 
Grade except 
different cover 


Male Flag 
_ Officer _ 

Same as Company 
Grade except 
different cover 


Same as Company 
Grade except 
different cover 


Same as Company 
Grade except 
different cover 


Same as Company 
Grade except 
different cover 
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Male WO/Co Grade 
Officer 

Male Field Grade 
Officer 

Male Flag 
Officer 

Blue-White Dress 
B 

m 

• 

Same as Company 
Grade except 
different cover 

Same as Company 
Grade except 
different cover 

Service A 

Note: garrison 
cover can be 
worn instead of 
combination 
cover with all 
service uniforms 

Same as Field 
Grade except 
different cover 
(unless garrison 
cover) 

yty « 

Same as Field 
Grade except 
different cover 
(unless garrison 
cover) 

Service B 

Same as Service C 
except with long 
sleeve and tie 

Same as Co 
Grade except 
different cover 
(unless garrison 
cover) 

Same as Co 
Grade except 
different cover 
(unless garrison 
cover) 

Service C 


Same as Co 
Grade except 
different cover 
(unless garrison 
cover) 

Same as Co 
Grade except 
different cover 
(unless garrison 
cover) 


122 










Service w Sweater 


Woodland Utility 


Dessert Utility 


Male WO/Co Grade 
Officer 





Male Field Grade 
Officer 


Male Flag 
Officer 








Table 6. Male Officer Uniforms 
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Female Non NCO 

Female NCO 

Female SNCO 

Evening Dress A 

N/A 

N/A 


Evening Dress B 

N/A 

N/A 

Same as A 

Blue Dress A 

Note: all Blue 
Dress female 
uniforms may be 
worn with slacks. 
Non NCO slacks 
do not have a 
blood stripe. 

Same as Blue Dress 

B except with 
medals 

Same as Blue 
Dress B except 
with medals 

Same as Blue 
Dress B except 
with medals 

Blue Dress B 

IV v • 



Blue Dress C 

Same as Blue Dress 
D except with long 
sleeve 

Same as Blue 
Dress D except 
with long sleeve 

Same as Blue 
Dress D except 
with long sleeve 
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Female Non NCO 


Female NCO 


Female SNCO 


Blue Dress D 





Blue-White Dress 
A 


Blue-White Dress 
B 


Same as Blue Dress 
A except with white 
slacks or white 
skirt. 


Same as Blue Dress 
A except with white 
slacks or white 
skirt. 


Same as Blue 
Dress A except 
with white slacks 
or white skirt. 


Same as Blue 
Dress A except 
with white slacks 
or white skirt. 


Same as Blue 
Dress A except 
with white slacks 
or white skirt. 


Same as Blue 
Dress A except 
with white slacks 
or white skirt. 


Service A 

Note: garrison 
cover can be worn 
instead of 
combination cover 
with all service 
uniforms 


Service B 
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Service C 


Service w Sweater 


Woodland Utility 


Dessert Utility 


Female Non NCO 



(Officer Shown) 




Female NCO 



(Officer Shown) 





Female SNCO 



(Officer Shown) 







Table 7. Female Enlisted Uniforms 
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Female WO/ Co 
Grade Officer 

Female Field 
Grade Officer 

Female Flag 
Officer 

Evening Dress A 

Same as Field 
Grade except for 
different sleeve 
insignia 

-i ddctfr-' 


Same as Field 
Grade except for 
different sleeve. 

Also scarlet 
waistcoat and 
plain front shirt 
are worn by Flag 
Officers. 

Evening Dress B 

Same as A 

Same as A 

Same as A 

Blue Dress A 

Note: all Blue 
Dress female 
uniforms may be 
worn with slacks. 

Same as Field 
Grade except 
different cover. 

\ 

- 's 3 

V; 1 — 


Same as Field 
Grade except 
different cover. 

Blue Dress B 

Same as Blue Dress 
A except with 
ribbons and badges. 

Same as Blue 
Dress A except 
with ribbons and 
badges. 

Same as Blue 
Dress A except 
with ribbons and 
badges. 

Blue Dress C 


Same as Co Grade 
except different 
cover. 

Same as Co Grade 
except different 
cover. 
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Blue Dress D 


Female WO/ Co 
Grade Officer 



Female Field 
Grade Officer 
Same as Co Grade 
except different 
cover. 


Female Flag 
Officer 


Same as Co Grade 
except different 
cover. 


Blue-White Dress 
A 


Blue-White Dress 
B 


(Enlisted Shown) 
Same as Blue Dress 
A except with white 
slacks or white 
skirt. 


Same as Blue Dress 
A except with white 
slacks or white 
skirt. 


Same as Blue 
Dress A except 
with white slacks 
or white skirt. 


Same as Blue 
Dress A except 
with white slacks 
or white skirt. 


Same as Blue 
Dress A except 
with white slacks 
or white skirt. 


Same as Blue 
Dress A except 
with white slacks 
or white skirt. 


Service A 

Note: garrison 
cover can be worn 
instead of 
combination cover 
with all service 
uniforms 


Service B 



Same as Co Grade 
except with 
different cover. 


Same as Co Grade 
except with 
different cover. 


Same as Co Grade 
except with 
different cover. 


Same as Co Grade 
except with 
different cover. 


(Enlisted Shown) 
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Female WO/ Co 
Grade Officer 

Female Field 
Grade Officer 

Female Flag 
Officer 

Service C 

Same as Field 
Grade except with 
different cover. 


Same as Field 
Grade except with 
different cover. 

Service w Sweater 

i 

J 


Woodland Utility 



t 

Dessert Utility 

Or 

* k **- 

|§ 

SPlpr 


Table 8. Fema 

e Officer Uniforms 
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III. WEB DESIGN CHECKLIST 


Name: 

Date: 

Rank: 

MOS: 



Navigation 

There is a clear indication of the current location 

There is a clearly-identified link to the Home page 

All major parts of the site are accessible from the Home page 

If necessary, a site map is available 

Site structure is simple, with no unnecessary levels 

If necessary, an easy-to-use Search function is available 

You can tell where you are immediately (clear title, 
description, image captions, etc.) 

There is an index, table of contents, or some other clear 
indicator of the contents of the site. 

User is able to move around within the site with ease 

Directions for using the site are provided and are easily 
understandable 

The links to other pages within the site are helpful and 
appropriate 

All links are current 

Compliance 

Always Sometimes Never 

Notes 




Speed 

Compliance 

Always Sometimes Never Notes 

No unnecessarily large graphics (slow 
download time) 

Server does not appear to be slow or often 
inaccessible 

All pages/links load in a timely manner 



Design 

Compliance 

Always Sometimes Never Notes 

ALT tags are used for all graphics, 
especially navigation graphics 

Black text on white background 
whenever possible for optimal legibility 
Plain-color backgrounds or extremely 
subtle background patterns 

Text is in a printable color 

Navigation in a consistent location 
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A familiar location for navigation bars 
The design keeps from scrolling 
horizontally 

One axis of symmetry for centered text 
on a page 

Scrolling is encouraged by splitting an 
image at the fold 

There is sufficient information to make 

the site worth visiting 

The information is clearly labeled and 

organized 

The same basic format is used 
consistently throughout site 
Information is easy to find (no more than 
three clicks, for example) 

Lists of links are well organized and 
easy to use 

User is able to quickly determine the 
basic content of the site. 

User is able to determine the intended 
audience of the site. 

The language used is simple and 
appropriate for the intended users 
The layout is clear 
Unnecessary animation is avoided 


Information Compliance 

_ Always Sometimes Never Notes 

The author(s) of the material on the site 
is clearly identified 

Information about the author(s) is 
available 

Author(s) appears qualified to present 

information on this topic 

The sponsor of the site is clearly 

identified 

A contact person or address is available 
so the user can ask questions or verify 
information 

Latest revision date is provided 
Content is updated frequently 
The purpose of this site is clear: 
business/commercial, entertainment, 
informational, news, personal page, 
persuasion 

The content achieves its intended 
purpose effectively 

The content appears to be complete (no 
“under construction” signs, for example) 

The content of this site is well organized 
The information in this site is easy to 
understand 
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This site offers sufficient information 

related to its purposes 

The content is free of bias, or the bias 

can be easily detected 

This site provides interactivity that 

increases its value 

The information appears to be accurate 
based on user’s previous knowledge of 
subject 

The information is consistent with 
similar information in other sources 
Grammar and spelling are correct 


Table 9. Web Design Checklist 
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IV. TESTING 


USMC Web Based Uniform Regulations 
Initial Testing Scenarios 

1. Please state your name, rank, MOS, and years experience. 

2. As you are going through this testing, please comment, positively or negatively, 
out loud regarding some of the following: 

a. Overall design 

b. Color scheme 

c. Navigation 

d. Accuracy of the information 

e. Text font and size 

f. Ease or difficulty of using the site 

g. Make any other comments that you feel will be helpful 

3. Although you may know the answer to the following scenarios off the top of your 
head, please use the web site to find the answers. 

4. You do not need to write down any answers, just simply keep a running dialog as 
you are working through the scenarios. 

5. What is the size of the hem on the trousers of the Service Dress C? 

6. Where does the Service Badge go on the Evening Dress B? 

7. Are you allowed to wear a flight jacket with the Blue Dress D? 

8. What are the measurements for a moustache? 

9. Are you required to wear ribbons with the Service Dress B? 

10. Where does the USMC emblem go on the pt gear sweatshirt? 

11. Find the requirements for Food Service Clothing. 

12. When are you required to wear your sleeves up on the Utility uniform? 

13. Please feel free to browse the site as you wish and make comments out loud. 

14. Please fill out our survey. 
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15. 


Thank you very much for participating in the testing of this site. Your input is 
invaluable to the functionality and success of this web site. 
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Name:Test Subject 1 

Date: 11 May 2006 

Rank .‘Captain 

MOS:0602 

Navigation 

Compliance 


There is a clear indication of the current location 
There is a clearly-identified link to the Home page 
All major parts of the site are accessible from the 
Home page 


If necessary, a site map is available 

Site structure is simple, with no unnecessary levels 

If necessary, an easy-to-use Search function is 

available 

You can tell where you are immediately (clear title, 
description, image captions, etc.) 

There is an index, table of contents, or some other 
clear indicator of the contents of the site. 

User is able to move around within the site with ease 
Directions for using the site are provided and are 
easily understandable 

The links to other pages within the site are helpful 
and appropriate 

All links are current 


Always Sometimes Never Notes 
x 
x 

x You have to go to 
rank/gender page 
to get access to 
the real 
information 
x 
x 

x 

x 


x 

x Links were 

inactive during the 
testing 
x 


Speed 

Compliance 

Always Sometimes Never Notes 

No unnecessarily large graphics (slow 

X 

download time) 


Server does not appear to be slow or 

X 

often inaccessible 


All pages/links load in a timely manner 

X 


Design 


Compliance 


ALT tags are used for all graphics, 
especially navigation graphics 
Black text on white background 
whenever possible for optimal legibility 
Plain-color backgrounds or extremely 
subtle background patterns 
Text is in a printable color 
Navigation in a consistent location 
A familiar location for navigation bars 


Always Sometimes Never 


x 


x 


X 

X 

X 


Notes 
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The design keeps from scrolling 

X 

horizontally 


One axis of symmetry for centered text 

X 

on a page 


Scrolling is encouraged by splitting an 


image at the fold 


There is sufficient information to make 

X 

the site worth visiting 


The information is clearly labeled and 

X 

organized 


The same basic format is used 

X 

consistently throughout site 


Information is easy to find (no more than 

X 

three clicks, for example) 


Lists of links are well organized and easy 

x No active links 

to use 


User is able to quickly determine the 

X 

basic content of the site. 


User is able to determine the intended 

X 

audience of the site. 


The language used is simple and 

X 

appropriate for the intended users 


The layout is clear 

X 

Unnecessary animation is avoided 

X 


Information 

Compliance 

Always Sometimes Never Notes 

The author(s) of the material on the site 

X 

is clearly identified 


Information about the author(s) is 

Not sure 

available 


Author(s) appears qualified to present 

I don’t know about 

information on this topic 

zee German. 

The sponsor of the site is clearly 

I don’t know 

identified 


A contact person or address is available 


so the user can ask questions or verify 


information 


Latest revision date is provided 


Content is updated frequently 

Don’t know 

The purpose of this site is clear: 

X 

business/commercial, entertainment. 


informational, news, personal page. 


persuasion 


The content achieves its intended 

X 

purpose effectively 


The content appears to be complete (no 

X 

“under construction” signs, for example) 


The content of this site is well organized 

X 

The information in this site is easy to 

X 

understand 


This site offers sufficient information 

X 
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related to its purposes 


The content is free of bias, or the bias 

X 

can be easily detected 


This site provides interactivity that 

Not yet 

increases its value 


The information appears to be accurate 

X 

based on user’s previous knowledge of 


subject 


The information is consistent with 

X 

similar information in other sources 


Grammar and spelling are correct 

X 


Table 10. Test Subject 1 
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Name:Test Subject 2 _ Date: 11 May 2006 _ 

Rank: Captain _ MOS: 0602 _ 

Navigation Compliance 

Always Sometimes Never 
Notes 

There is a clear indication of the current location X 

There is a clearly-identified link to the Home page X 

All major parts of the site are accessible from the Home page X 
If necessary, a site map is available X 

Site structure is simple, with no unnecessary levels X 

If necessary, an easy-to-use Search function is available X Didn’t 

see a 
search 


You can tell where you are immediately (clear title, description, x 
image captions, etc.) 

There is an index, table of contents, or some other clear x 
indicator of the contents of the site. 


field 

Liked 

across 


top 

User is able to move around within the site with ease X 

Directions for using the site are provided and are easily X 

understandable 

The links to other pages within the site are helpful and x 
appropriate 

All links are current X 














There is sufficient information to make 
the site worth visiting 
The information is clearly labeled and 
organized 

The same basic format is used 
consistently throughout site 
Information is easy to find (no more 
than three clicks, for example) 

Lists of links are well organized and 
easy to use 

User is able to quickly determine the 
basic content of the site. 

User is able to determine the intended 
audience of the site. 

The language used is simple and 
appropriate for the intended users 
The layout is clear 
Unnecessary animation is avoided 




Information 


The author(s) of the material on the site 
is clearly identified 

Information about the author(s) is 
available 

Author(s) appears qualified to present 

information on this topic 

The sponsor of the site is clearly 

identified 

A contact person or address is available 
so the user can ask questions or verify 
information 

Latest revision date is provided 
Content is updated frequently 
The purpose of this site is clear: 
business/commercial, entertainment, 
informational, news, personal page, 
persuasion 

The content achieves its intended 
purpose effectively 

The content appears to be complete (no 
“under construction” signs, for example) 
The content of this site is well organized 
The information in this site is easy to 
understand 

This site offers sufficient information 

related to its purposes 

The content is free of bias, or the bias 

can be easily detected 

This site provides interactivity that 

increases its value 

The information appears to be accurate 
based on user’s previous knowledge of 


Compliance 

Always Sometimes Never Notes 


Didn’t see contact 
link 

unknown 


Uniform man unclear 
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subject 

The information is consistent with 
similar information in other sources 
Grammar and spelling are correct 


Table 11. Test Subject 2 


Inches “ 


Name:Test Subject 3 


Rank:LtCol 


Navigation 

There is a clear indication of the current location 

There is a clearly-identified link to the Home page 

All major parts of the site are accessible from the Home 

page 

If necessary, a site map is available 

Site structure is simple, with no unnecessary levels 

If necessary, an easy-to-use Search function is available 

You can tell where you are immediately (clear title, 

description, image captions, etc.) 

There is an index, table of contents, or some other clear 
indicator of the contents of the site. 

User is able to move around within the site with ease 
Directions for using the site are provided and are easily 
understandable 

The links to other pages within the site are helpful and 

appropriate 

All links are current 


Date: 11 May 2006 


MOS:7562 


Compliance 

Always Sometimes Never Notes 


X 



X 



X 

X 

Didn’t see one 

X 

X 

Didn’t see one 

X 



X 



X 

X 

No directions 
necessary 

X 

X 

Not all links 
operational 



Speed 


No unnecessarily large graphics (slow 
download time) 

Server does not appear to be slow or 
often inaccessible 

All pages/links load in a timely manner 


Compliance 

Always Sometimes Never Notes 


X 



Design 


ALT tags are used for all graphics, 
especially navigation graphics 
Black text on white background 
whenever possible for optimal legibility 
Plain-color backgrounds or extremely 
subtle background patterns 


Compliance 

Always Sometimes Never Notes 
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Text is in a printable color 

X 


Navigation in a consistent location 

X 


A familiar location for navigation bars 

X 


The design keeps from scrolling 

X 


horizontally 

One axis of symmetry for centered text 

X 


on a page 

Scrolling is encouraged by splitting an 


No horizontal 

image at the fold 


scrolling 

There is sufficient information to make 

X 

implemented 

the site worth visiting 

The information is clearly labeled and 

X 


organized 

The same basic format is used 

X 


consistently throughout site 

Information is easy to find (no more than 

X 


three clicks, for example) 

Lists of links are well organized and easy 

X 


to use 

User is able to quickly determine the 

X 


basic content of the site. 

User is able to determine the intended 

X 


audience of the site. 

The language used is simple and 

X 


appropriate for the intended users 

The layout is clear 

X 


Unnecessary animation is avoided 

X 



Information 

Compliance 




Always Sometimes Never 

Notes 

The author(s) of the material on the site 
is clearly identified 

Information about the author(s) is 
available 

X 

X 

Didn’t see addt’l info 

Author(s) appears qualified to present 
information on this topic 

The sponsor of the site is clearly 
identified 

X 

X 

Didn’t see a sponsor 

A contact person or address is available 
so the user can ask questions or verify 
information 


X 

Didn’t see contact 
info 

Latest revision date is provided 


X 

Didn’t see one 

Content is updated frequently 

The purpose of this site is clear: 
business/commercial, entertainment, 

informational, news, personal page. 

X 

X 

Unknown 

persuasion 

The content achieves its intended 

X 



purpose effectively 

The content appears to be complete (no 
“under construction” signs, for example) 

X 
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The content of this site is well organized X 
The information in this site is easy to X 
understand 

This site offers sufficient information X 
related to its purposes 

The content is free of bias, or the bias X 
can be easily detected 

This site provides interactivity that X 

increases its value 

The information appears to be accurate X 
based on user’s previous knowledge of 
subject 

The information is consistent with X 

similar information in other sources 
Grammar and spelling are correct X 

Table 12. Test Subject 3 


Name: Test Subject 4 _ 

Rank :Capt _ 

Navigation 

There is a clear indication of the current location 
There is a clearly-identified link to the Home page 
All major parts of the site are accessible from the 
Home page 

If necessary, a site map is available 

Site structure is simple, with no unnecessary levels 

If necessary, an easy-to-use Search function is 

available 

You can tell where you are immediately (clear title, 
description, image captions, etc.) 

There is an index, table of contents, or some other 
clear indicator of the contents of the site. 

User is able to move around within the site with 
ease 

Directions for using the site are provided and are 
easily understandable 

The links to other pages within the site are helpful 
and appropriate 


Date: 11 May 2006 _ 

MGS: 0180 _ 

Compliance 

Always Sometimes Never Notes 
X 
X 
X 

X 

X 

X Would be nice to 
easily find 

information 

X 

X 

X 

X 

X Link to previous 

page was placed 
in different 

locations 



Speed Compliance 

_ Always Sometimes Never Notes 

X 


No unnecessarily large graphics (slow 
download time)_ 
















Server does not appear to be slow or 

X 


often inaccessible 



All pages/links load in a timely manner 

X 

Hard to say since the 



pages were local 


Design 

Compliance 

Always Sometimes Never 

Notes 

ALT tags are used for all graphics. 


X 

Should be 

especially navigation graphics 



descriptive. The text 




on a few of the 




graphic images were 




difficult to read 

Black text on white background 

X 



whenever possible for optimal legibility 




Plain-color backgrounds or extremely 


X 

Good water marks 

subtle background patterns 




Text is in a printable color 

X 



Navigation in a consistent location 


X 

Link to previous page 

A familiar location for navigation bars 


X 

The back to top link 




was buried in the 




bottom of the page 

The design keeps from scrolling 

X 



horizontally 




One axis of symmetry for centered text 

X 



on a page 




Scrolling is encouraged by splitting an 



Ignored 

image at the fold 




There is sufficient information to make 


X 

References specific 

the site worth visiting 



items in text, but 




forces user to consult 




reference 

The information is clearly labeled and 


X 


organized 




The same basic format is used 

X 



consistently throughout site 




Information is easy to find (no more 


X 


than three clicks, for example) 




Lists of links are well organized and 


X 


easy to use 




User is able to quickly determine the 

X 



basic content of the site. 




User is able to determine the intended 


X 


audience of the site. 




The language used is simple and 


X 

The order is difficult. 

appropriate for the intended users 




The layout is clear 

X 



Unnecessary animation is avoided 

X 
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Information 

Compliance 

Always Sometimes Never Notes 

The author(s) of the material on the site 

X 

is clearly identified 


Information about the author(s) is 

X 

available 


Author(s) appears qualified to present 

X 

information on this topic 


The sponsor of the site is clearly 

X 

identified 


A contact person or address is available 

X 

so the user can ask questions or verify 


information 


Latest revision date is provided 

X 

Content is updated frequently 

Under Development 

The purpose of this site is clear: 

X 

business/commercial, entertainment. 


informational, news, personal page. 


persuasion 


The content achieves its intended 

X 

purpose effectively 


The content appears to be complete (no 

X 

“under construction” signs, for example) 


The content of this site is well organized 

X 

The information in this site is easy to 

X 

understand 


This site offers sufficient information 

X 

related to its purposes 


The content is free of bias, or the bias 

X 

can be easily detected 


This site provides interactivity that 

X 

increases its value 


The information appears to be accurate 

X 

based on user’s previous knowledge of 


subject 


The information is consistent with 

X 

similar information in other sources 


Grammar and spelling are correct 

X Few typos 


Table 13. Test Subject 4 
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V. XHTML (HTML AND CSS) CODE EXAMPLE 


The following code contains the full CSS style sheet, the code for the start page 
and exemplary the code one of the uniform pages. And while the CSS code is rather 
extensive the very similar HTML of the start page and the Uniform page demonstrate the 
simple include statements used to assemble the output HTML files. 

A. CSS 

body { 

font-family: Arial, Helvetica, sans-serif; 
color: #0 AO AO A; 

background: #F0F0F0 url(../images/Emblem_backgriund.gif) no-repeat fixed 0% 
65% [important; 

background: #F0F0F0 url(../images/Emblem_backgriund.gif) no-repeat scroll -1% 

340px ; 

behavior: url(/css/csshover2.htc); 

} 


* {padding:0;margin:0;} 
table { 

font-family: Arial, Helvetica, sans-serif; 
font-size: llpx; 
line-height: 15px; 
border-top: lpx solid #000000; 
border-right: lpx solid #000000; 
border-collapse: collapse; 

} 

tr { 

border: lpx solid #000000; 

} 

td{ 

padding: 2px; 

border: lpx solid #000000; 

} 


#container { 
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width: 90%; 
min-width: 670px; 
margin: lOpx auto auto 30px; 
border-top-width: lOpx; 
border-top-style: solid; 
border-top-color: #0A0A0A; 
border-bottom-width: lOpx; 
border-bottom-style: solid; 
border-bottom-color: #990000; 

background: #FEFEFE url(../images/Emblem_backgriund.gif) no-repeat fixed 0% 
65% [important; 

background: #FEFEFE url(../images/Emblem_backgriund.gif) no-repeat scroll - 
35px 320px ; 

} 

#logo { 

margin: Opx; 
padding: Opx; 
height: 90px; 

background-attachment: scroll; 
background-image: url(../images/logo_mod.gif); 
background-repeat: repeat-x; 
background-position: left; 
background-color: #0A0A0A; 

} 

#Fe w_proud_logo { 
float:left; 

} 

#logo #page_title { 
float: right; 
margin-right: lOpx; 
padding-top: 3.5 em; 

font-family: Arial, Helvetica, sans-serif; 
font-style: normal; 
font-weight: bold; 
text-transform: uppercase; 
color: #FEFEFE; 

} 

#top_nav { 

width: 100%; 
height:21px; 

baekground-eolor:#0A0A0A; 


146 



padding:Opx; 
float: left; 

border-bottom-width: lem; 
border-bottom-style: solid; 
border-bottom-color: #990000; 

} 

/*Only for the start page welcome banner*/ 

#navlist { 

font-family: Arial, Helvetica, sans-serif; 

font-size: 12px; 

font-style: normal; 

font-weight: 600; 

text-transform: uppercase; 

text-align: center; 

letter- spacing: 0.07em; 

color: #FEFEFE; 

margin-top: 3px; 

margin-bottom: 3px; 

} 

#breadcrumb { 

background-color:#990000; 
color:#FEFEFE; 
margin: 5px Opx 2px; 
padding: Opx; 
line-height: normal; 

font-family: Geneva, Arial, Helvetica, sans-serif; 
text-decoration: none; 
text-indent: lOpx; 
font-size: 12px; 


#breadcrumb a { 

color: #FEFEFE; 
text-decoration: underline; 


#left_nav { 

margin: lem Oem Oem; 
padding: Opx; 
float: left; 
width: 20%; 
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} 

#pic_col { 

float: left; 
width: 55%; 
padding-top: lOpx; 


#pic_col .image_text{ 

margin-left:30%; 
font-size :.8em; 

} 

#pic_col .image_text_small{ 
margin-left:30%; 
font-size:.6em; 


} 


#pic_col .cover_pictures{ 
float:left; 

} 

#pic_col .cover_pictures p{ 

font-size:llpx; 

margin-left:20%; 

} 


#iight_col { 

width: 20%; 
margin: 5px Opx Opx; 
padding: Opx 3px 20px 5px; 
clear: none; 
float: right; 

font-family: Arial, Helvetica, sans-serif 
font-size: 12px; 
font-style: normal; 
font-weight: normal; 

} 
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#details { 

margin-bottom: lOpx; 
padding: Opx; 
font-size: 1.3em; 
displaymone; 

} 

#details_local { 

margin-bottom: lOpx; 
padding: Opx; 
font-size: 1.3em; 
displaymone; 

} 

#optional_items { 
margin: Opx; 

font-size: 1.3em; 
displaymone; 

} 

#detailed_text { 

margin:Opx ; 
padding: lOpx 30px 5px; 
clear: both; 

font-family: Arial, Helvetica, sans-serif; 

font-size: 14px; 

font-style: normal; 

font-weight: normal; 

font-variant: normal; 

color: #0A0A0A; 

border-top-width: lpx; 

border-top-style: dotted; 

border-top-color: #0A0A0A; 

list-style-position:outside; 

} 

#detailed_text h3 { 

margin-top:5px; 

} 


#detailed_text ol li{ 

margin-top:5px; 

} 

#detailed_text ol li ol li{ 
margin-top:2px; 
list-style-position:inside; 

} 
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#detailed_text ol li ol li ol{ 
margin-left: lOpx; 
margin-top:2px; 
list-style-position:inside; 

} 

#footer { 

margin: Opx; 

padding: Opx Opx Opx 5px; 
color: #FFFFFF; 
background-color: #0A0A0A; 
clear: both; 

border-top-width: thin; 
border-top-style: solid; 
border-top-color: #000000; 
height: 20px; 

} 

#copy p{ 

height: 100%; 
margin: Opx; 
padding: Opx; 

background-color: #0A0A0A; 

clear:both; 

text-align: left; 

float: left; 

font-family: Arial, Helvetica, sans-serif; 

font-size: 12px; 

font-style: normal; 

line-height: normal; 

font-weight: lighter; 

text-transform: none; 

color: #FEFEFE; 

vertical-align: middle; 

} 


/* ____ */ 

/* extlinks 

*/ 

/* __ */ 


#ext_nav #int_navlist { 
float:left; 
margin-left: 5em; 

} 
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#ext_nav #ext_navlist { 
float:right; 
margin-right: lOpx; 

} 

#ext_nav ul { 

text-align: center; 
background-color: #0A0A0A; 
font-family: Arial, Helvetica, sans-serif; 

/* line-height: 5px; */ 

margin: Opx;/* fixes Firefox 0.9.3 */ 
padding-top: 2px; 
padding-bottom: 2px; 
font-size: 12px; 

} 

#ext_nav ul li 

{ 

display: inline; 
padding-left: 0; 
padding-right: 0; 
padding-bottom: 2px; 

/* matches link padding except for left and right */ 
padding-top: 2px; 

} 

#ext_nav ul li a 

{ 

padding-left: lOpx; 
padding-right: lOpx; 
padding-bottom: 5px; 
padding-top: 5px; 
color: #FEFEFE; 
text-decoration: none; 
border-right: lpx solid #FEFEFE; 
border-left-width: lpx; 
border-left-style: solid; 
border-left-color: #FEFEFE; 

} 

#ext_nav ul li a:hover 

{ 

background-color: #990000; 
color: #FEFEFE; 
border: thin solid #FEFEFE; 

} 
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/* ________ */ 

/* drop_down 

*/ 

/* _ */ 


/* the horizontal menu starts here */ 
div#listmenu { 

width: 100%; 

font-size:0.75em; /* SET FONT-SIZE HERE */ 

margin-top:2px; 

margin-bottom: 2px; 

z-index: 1; 

font-weight: bold; 

} 

div#listmenu ul { 

margin:0 0 0 10%;/* indents ul from edge of container - NOTE: diff value for IE 
in hacks below */ 

} 

div#listmenu li { 

floatdeft; /* causes the list to align horizontally instead of stack */ 
positiomrelative; /* positioning context for the absolutely positioned drop-down 

*/ 

list-style-type:none; /* removes the bullet off each list item */ 
baekground-eolor:#0A0A0A; /*sets the background of the menu items */ 
border-right: lpx solid #FEFEFE; /* creates dividing lines between the li elements 

*/ 

z-index: 1; 

} 

div#listmenu li:first-child { 

border-left: lpx solid #FEFEFE; /*the first vertial line on the menu */ 

} 

div#listmenu li:hover { 

background-color:#990000; /*sets the background of the menu items */ 
border-left-width: lpx; 
border-left-style: solid; 
border-left-color: #FEFEFE; 

} 

div#listmenu a { 
display :block; 

padding:2px 6px; /*creates space each side of menu item's text */ 
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text-decoration:none; /* removes the underlining of the link */ 
color:#FEFEFE; /* sets the type color */ 

} 

div#listmenu a:hover { 
color:#FEFEFE; 

} 

/* the menu ends here */ 

/* the drop-down starts here */ 
div#listmenu ul li ul { 
margin :0px; 

z-index:10; /* puts drop-down on top of div - Safari needs this as menu is lpx 
higher */ 

positiomabsolute; /* positions the drop-down ul in relation to its relatively 
positioned li parent */ 

width: lOem; /*sets the width of the menu - in combo with the li's 100% width, 
makes the menu stack*/ 

border-right:0; /* stops SCBs drops having two right borders - they inherit the 
border, IE doesn't */ 

left:-lpx; /*aligns the drop exactly under the menu */ 

} 

div#listmenu ul li ul li {padding:0; 

width: 100%; /* makes the list items fill the list container (ul) */ 
border-left: lpx solid #FEFEFE; /* three sides of each drop-down item */ 
border-bottom: lpx solid #FEFEFE; 
border-right: lpx solid #FEFEFE;} 
div#listmenu ul li ul li a {padding: lpx .5em;} 
div#listmenu ul li ul li:first-child { 

border-top: lpx solid #FEFEFE; /*the top edge of the dropdown */ 

} 

/* make the drop-down display as the menu is rolled over */ 

div#listmenu ul li ul {display :none;} /* conceals the drop-down when menu not hovered 
*/ 

div#listmenu ul li:hover ul {display:block; } /* shows the drop-down when the menu is 
hovered */ 

/* pop-out starts here */ 
body div#listmenu ul li ul li ul { 
positiomabsolute; 

visibility:hidden; /* same effect as displaymone in this situation */ 

top:-lpx; 

left:10em; 

} 

div#listmenu ul li ul li:hover ul {visibility:visible;} /* same effect as display:block in this 
situation */ 

/* second level popouts start here*/ 
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div#listmenu ul li ul li:hover ul li ul {visibility:hidden;} 

div#listmenu ul li ul li ul li:hover ul {visibility:visible;} /* same effect as display:block in 
this situation */ 

/* THE HACK ZONE - */ 

/* hack for IE (all flavors) so the menu has a vertical line on the left */ 

* html div#listmenu ul { 

floatrleft; /* makes the ul wrap the li's *1 

border-left: lpx solid #FEFEFE; /* adds the rightmost menu vertical line to the ul 

*/ 

margin-left:5%; /* IE doubles the given value above - why? */ 

} 

/* add a top line to drops and pops in IE browsers - can't read :first-child */ 

* html div#listmenu ul li ul { 

border-top: lpx solid #FEFEFE; 

border-left:Opx; /* stops the drop inheriting the ul border */ 

} 

/* the Tantek hack to feed IE Win 5.5-5.0 a lower value to get the pop-out to touch the 
drop-down */ 

* html div#listmenu ul li ul li ul { 
left:9.85em; 

voice-family: 
voice-family :inherit; 
left: lOem; 

} 

/* and the "be nice to Opera and Firefox(ck)" rule */ 
html>body div#listmenu ul li ul li ul { 
left: lOem; 

} 

/* an Opera-only hack to fix a redraw problem by invisibly extending the ul */ 

/* the first-level drop stays open for lOOpx below the bottom but at least it works */ 

/* this can be reduced to as little as 22px if you don't have pop-outs */ 

/* the pop-out menu stays open for 22px below the bottom but at least it works */ 

@media all and (min-width: 0px){ 
body div#listmenu ul li ul {padding-bottom:lOOpx;} 
body div#listmenu ul li ul li ul {padding-bottom:22px;} 

ul li ul li ul li ul li:hover {visibility:visible;} /* same effect as display:block in this 
situation */ 

} 

/*end Opera hack */ 

/* END OF HACK ZONE */ 

/* the drop-down ends here */ 

/* END OF LIST-BASED MENU */ 
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/* finally after feeding values to all others, we deal with MAc5 IE */ 

/* IE5 Mac can't do drop-downs so we need to present the info in a different way*/ 

/* we present the drop down choices in a row and never show any second-level drops */ 

/* this stylesheet is read by IE5 Mac only - hack omits 'url' and leave no space between 
@ import and (" */ 


/* ________ */ 

/* left_nav 

*/ 

/* _______ */ 


.menu { 

width: 75%; 

} 

#right_col ,menu{ 

margin-top: lOpx; 
float:right; 

} 


.menu ul { 

list-style: none; 
margin: 0; 
padding: 0; 

} 

.menu a, .menu h2 { 

font: bold 16px arial, helvetica, sans-serif; 

display: block; 

border-width: lpx; 

border-style: solid; 

border-color: #ccc #888 #555 #bbb; 

margin: 0; 

padding: 2px 3px; 

} 

.menu h2 { 

color: #FEFEFE; 
background: #0A0A0A; 
text-transform: uppercase; 

} 


.menu #present{ 

color: #FEFEFE ; 
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background: #990000; 
text-decoration: none; 

} 

.menu a { 

color: #FEFEFE ; 
background: #313643; 
text-decoration: none; 

} 


.menu a:hover { 

color: #FEFEFE; 
background:#990000; 

} 

.menu li { 

position: relative; 

} 

.lower_list{ 

margin-top: lem; 

} 


#validation {positiomrelative; 

top:70px; 

left:30px; 


} 


/* _____ */ 

/* hacks for the vertical nav menu 

*/ 

/* ___ */ 


[if IE]> 

.menu ul li [float: left; width: 100%;} 

<![endif] 

[if It EE 7] > 

.menu ul li [float: left; width: 100%;} 
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.menu ul li a {height: 1%;} 


.menu a, .menu h2 { 

font: bold 0.7em/1.4em arial, helvetica, sans-serif; 

} 

<![endif] 

B. HTML AND PHP OF START PAGE 
1. Index Page 

<?php $serverRoot = $_SERVER['DOCUMENT_ROOT']; ?> 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtmll/DTD/xhtmll-transitional.dtd"> 

<!— saved from url=(0014)about:internet —> 

<html xmlns="http://www.w3.org/1999/xhtml"> 

<head> 

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-l" /> 
<title>The Marine Corps Online Uniform Manual</title> 

<link href="css/level_style.php" rel="stylesheet" type="text/css" /> 


</head> 

<body> 


<?php $includcFile = $serverRoot.'/start_content.php'; 

if 

(file_exists($includeFile) && is_readable($includeFile)){ 

include($includeFile); } ?> 

</body> 

</html> 

2. Content of start page 

<?php $serverRoot = $_SERVER['DOCUMENT_ROOT']; ?> 

<div id-'container"> 

<div id="logo"xa name="pageTop"x/a> 
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<div id="Few_proud_logo"ximg 

alt="Few_Proud_Logo" /></div> 


src="images/Few_Proud_Logo.gif 


<div id="page_title"x?php $includeFile = 'page_title.php'; 

if 

(file_exists($includeFile) && is_readable($includeFile)){ 

include($includeFile); } ?x/div> 

</div> 

<div id="top_nav"> 

<?php $includeFile = 'banner.htm'; 

if 

(file_exists($includeFile) && is_readable($includeFile)){ 
include($includeFile); } ?> 

</div> 


<div id="left_nav"> 

<?php $includeFile = $serverRoot.'/navigation/left_nav.php'; 

if 

(file_exists($includeFile) && is_readable($includeFile)){ 

include($includeFile); } ?> 

</div> 

<div id="pic_col"ximg src="images/image.gif" alt="image" width="600" 
height="332" /x/div> 


<div id="right_col"> 

<div id="details"> 

<?php $includeFile 

$serverRoot.7right_col_details/uniform_details.htmT; 

if 

(file_exists($includeFile) && is_readable($includeFile)){ 
include($includeFile); } ?x/div> 

<div id="optional_items"> 

<?php $includeFile = $serverRoot.7optionalItems/optional_items.htmT; 

if 

(file_exists($includeFile) && is_readable($includeFile)){ 

include($includeFile); } ?x/div> 

</div> 
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<div id="detailed_text"> 

<?php $includeFile = 'bottom_text/bottom.htm'; 

if 

(file_exists($includeFile) && is_readable($includeFile)){ 
include($includeFile); } ?></div> 


<div id="footer"> 

<div id="copy"x?php $includeFile = $serverRoot.'/copyright.php'; 

if 

(file_exists($includeFile) && is_readable($includeFile)){ 
include($includeFile); } ?></div> 

<div id="ext_links"x?php $includeFile = $serverRoot.'/navigation/ext_links.htm'; 

if 

(file_exists($includeFile) && is_readable($includeFile)){ 

include($includeFile); } ?x/div> 

</div> 

</div> 


<div id="validation"> 

<p> 

<a href="http://validator.w3.org/check?uri=referer"ximg 
src="images/valid-xhtmll0.png" 

alt="Valid XHTML 1.0 Transitional" height="20" width="66" /x/a> 

<a href="http://www.php.net/"ximg 

src=" images/php5-po wer-micro .png" 
alt="Powered by PHP 5.1" /> 

</a> 

</p> 


</div> 


3. Uniform Page Example 

<?php $serverRoot = $_SERVER['DOCUMENT_ROOT']; ?> 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtmll/DTD/xhtmll-transitional.dtd"> 

<!— saved from url=(0014)about:internet —> 
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<html xmlns="http://www.w3.org/1999/xhtml"> 

<head> 

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-l" /> 
<title>The Marine Corps Online Uniform Manual</title> 

<link href="css/level_style.php" rel="stylesheet" type="text/css" /> 


</head> 

<body> 


<?php $includeFile = $serverRoot.'/page_content.php'; 

if 

(file_exists($includeFile) && is_readable($includeFile)){ 

include($includeFile); } ?> 

</body> 

</html> 
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